Eccezioni di lancio nei provider di configurazione dell'applicazione

Question

Eccezioni di lancio nei provider di configurazione dell'applicazione

#1 da (1 voti)
#2 da (1 voti)

1

Domanda semplice: qual è la prassi migliore / comune in merito agli errori di lancio per i provider di configurazione dell'applicazione?

Given è una semplice sorgente di configurazione basata su valori / chiavi:

class Configuration
    string GetValue(key);
    void SetValue(key, value);

O più esteso, con la possibilità di aggiungere / rimuovere elementi chiave / valore

class Configuration
    string GetValue(key);
    void SetValue(key, value);
    void AddKeyValuePair(string key, string value);
    void RemoveKeyValuePair(string key);

Non lanciare eccezioni su metodi come GetValue() ha il vantaggio di non interrompere il flusso dell'applicazione e rendere il codice più facile da leggere a causa della mancanza di gestione delle eccezioni, ecc. Permette anche di usare operatori condizionali nulli (forse monadi) o operatori a coalescenza nulla per es impostazione dei valori predefiniti:

var value = configuration.GetValue("myKey") ?? "Hello World";

Restituisce null dice semplicemente all'utente: "Whoops, non ha nulla da restituire poiché non è stato impostato nulla / there".

Comunque ..

Se evitassi di lanciare eccezioni, cosa succederebbe se provassi ad aggiungere una coppia chiave / valore che è già disponibile? O imposta il valore con una chiave che non è presente nella memoria sottostante? O rimuovendo una coppia chiave / valore che non è disponibile? Sarebbe ovvio per l'utente che semplicemente non accada nulla quando proviamo a rimuovere una coppia di chiavi non esistente?

Qual è l'approccio preferito per la configurazione dell'applicazione?

c# programming-practices exceptions exception-handling configuration

posta artganify 07.10.2015 - 15:15

fonte

2 risposte

Leggi altre domande sui tag c# programming-practices exceptions exception-handling configuration

Utilizzo di MonoDevelop per lo sviluppo di software commerciale In javascript, le proprietà dell'oggetto devono essere dichiarate in cima alla funzione?

score 1 · Answer 1

Sembra che tu sia sull'orlo di Programmazione orientata alle ferrovie .

Come per la maggior parte delle cose non c'è un modo giusto per farlo, solo compromessi. Le eccezioni sono costose quando vengono lanciate, ma sono una pratica abbastanza normale in C #. Al contrario, restituire un pass / fail significa che devi controllare il valore di ritorno (se ti interessa che fallisca).

Usando le eccezioni, dovranno racchiudere le chiamate al tuo codice nei blocchi try / catch (che non trovo mai divertenti). Se si desidera evitare l'utilizzo di eccezioni per errori previsti (chiave non trovata), cambierei l'API per rendere esplicito il valore di ritorno in merito alla modifica della configurazione. E rendere i metodi chiari come previsto precondizioni (presente chiave o no). In questo modo, il chiamante può scegliere un metodo che consente loro di ignorare il valore restituito. Oppure possono gestire esplicitamente il caso in cui non è stato possibile eseguire la modifica richiesta.

Ecco una classe di esempio con metodi più espliciti e valori di ritorno.

class Configuration
    string GetValue(string key); // presence expected, null means not there
    bool ChangeExistingValue(string key, string value); // only change if present
    bool AddNewKeyValuePair(string key, string value); // add only if not present
    void AddOrUpdateValue(string key, string value); // obvious use
    bool RemoveKeyValuePair(string key); // obviously presence is expected

Quando chiamato, posso scegliere il metodo di cui ho bisogno (C #):

// don't want to add the value if it's not already there
// return value of false is ignored
config.ChangeExistingValue("asdf", "fdsa");

// -- vs --

// there is a problem if this value is not there
if (!config.ChangeExistingValue("asdf", "fdsa"))
    throw new SomeException(...);

// -- vs --

// I don't care about before, just put it in there now
config.AddOrUpdateValue("asdf", "fdsa");

score 1 · Answer 2

Prima di tutto: per cosa è una configurazione?

Una configurazione consente all'utente di modificare il comportamento della nostra applicazione per influenzare il comportamento dell'applicazione in un modo o nell'altro. L'applicazione si comporta in un certo modo sano ma l'utente desidera personalizzare il comportamento.

Ciò detto la prospettiva per le tue risposte è la seguente:

If I'd avoid throwing exceptions, what would happen if I try to add a key/value pair which is already available?

La tua applicazione ha un comportamento predefinito corretto. Se l'utente decide di sovrascriverlo, va bene. Se l'utente cambia idea, dovrebbe essere in grado di farlo senza problemi a patto che l'applicazione sia in uno stato normale.

Or set the value with a key that isn't there in the underlying storage?

Se la tua configurazione dovesse accettare solo determinati valori, dovresti far sapere ai tuoi utenti che.

Or removing a key/value pair that isn't available?

Il punto d'appoggio di questa azione è che non vuoi un comportamento personalizzato e preferisci fare affidamento sui valori predefiniti. Dovresti gestire questo caso con garbo e accettarlo in caso tu autorizzi il set -operation in altri casi a far sapere al tuo utente che questo valore di configurazione non è consentito.

Would it be obvious for the user that simply nothing happens when we tries to remove a none-existing key pair?

No. Ma gli importerebbe?

Nel caso in cui l'utente desideri ottenere un valore, che non è impostato in modo esplicito, restituisce l'impostazione predefinita (sane).

Riguardo alle eccezioni:

Exceptions sono proprio questo: comportamento eccezionale nel caso in cui non si potesse gestire la situazione. Pensa a Samurai : realizza la tua missione o muori provando.

L'impostazione delle opzioni non consentite è eccezionale , quindi sarebbe corretto lanciare un'eccezione.