Utilizzo della configurazione per determinare se gestire l'eccezione o farlo esplodere

Question

Utilizzo della configurazione per determinare se gestire l'eccezione o farlo esplodere

#1 da (8 voti)
#2 da (2 voti)
#3 da (0 voti)
#4 da (0 voti)

3

In un progetto parallelo su cui sto lavorando Mi è venuto in mente un modo per gestire le eccezioni che è regolabile in base alla configurazione. Quindi un blocco try / catch potrebbe apparire come questo:

try
{
    fileHelper.MoveFile(file, destFolder);
}
catch (IOException ex)
{
    if (exceptionHandler.HandleException(ex))
    {
        return ResultCode.Fail;
    }
    throw;
}

La granularità della gestione delle eccezioni è controllata tramite un enum impostato nel file app.config:

public enum SystemFailureMode
{
    AlwaysThrow = -1,
    Aggressive = 0,
    Standard = 1,
    Lenient = 2
}

Determina se un'eccezione è "gestita" e restituita come un errore, o se bolle e arresta il sistema. All'inizio pensavo di aver scoperto un nuovo modello di design, ma ora sembra che sia probabilmente un anti-pattern. Cosa ne pensate?

Dopo aver esaminato i commenti e pensato a me stesso, ho deciso che questo è decisamente un anti-modello. Il fatto che questo abbia il potenziale per trasformare i test delle unità di scrittura in un incubo è sufficiente a disattivarmi.

design-patterns exception-handling configuration

posta Repo Man 18.02.2014 - 01:42

fonte

4 risposte

2

Dipende dalla definizione di "eccezione"

Che cosa significa avere un'eccezione? Il solito pensiero è che qualcosa ha impedito che l'esecuzione diventasse normale. Qualcosa è sbagliato." Se non viene gestito, nulla in futuro sarà "corretto".

La grande domanda per te è "qual è lo stato del sistema quando viene lanciata l'eccezione?" Quello di cui stai parlando è la logica regolabile nel recupero dopo che è stata generata un'eccezione. Se ciò abbia un senso o no è caso specifico. Deve essere logico dire "lascia che l'utente decida se fermarmi qui o se dovrei fare il mio piano di backup". Se ha senso lasciare questa scelta nelle mani dell'utente per bontà, fallo! Se ciò sembra divertente, probabilmente non dovresti dare loro un tale potere. In alcuni casi, l'eliminazione delle eccezioni è un business MOLTO disordinato e lasciare che l'utente in quella sporca scappatella possa portare a direzioni molto brutte.

Detto questo, ho visto la versione estrema del tuo pattern: c'era un gestore di eccezioni per l'intero programma. Se è stata generata un'eccezione e è stato scelto PRODUCTION_MODE, l'intero programma è stato praticamente riavviato.

risposta data 18.02.2014 - 02:52

fonte

0

Hai implementato una "eccezione riassumibile". Molte persone considerano le eccezioni ripristinabili come un anti-modello, in parte perché non è quasi mai necessario, in parte perché è un modello che può essere abusato.

Dopo aver implementato una "eccezione riassumibile", aggiungi un segnale per controllare come viene gestita l'eccezione. Questo è normale e non è l'anti-modello. I valori di stato comuni includono "forza ignora tipo di eccezione", "gestisci le eccezioni come programmate" e "lancia direttamente al livello superiore".

A mio parere, le eccezioni di resume sono una buona cosa quando si tratta di processi non presidiati, paralleli, sincroni / asincroni con risorse condivise. Non si desidera un'eccezione sul controllo del processo per interrompere l'intero processo del server. Non vuoi che un'eccezione si bolla alla "cima", perché non c'è niente e nessuno nella parte superiore. La maggior parte delle eccezioni che non vuoi trattare come eccezioni.

L'esempio più noto di eccezioni ripristinabili è BASIC "su errore riprendi successivo", equivoco al tuo "return ResultCode.Fail". "Errore" è un termine arcaico per "Eccezione": "resume next" è il segnale di controllo del gestore di eccezioni. Questo schema era comunemente usato per avvolgere comunicazioni seriali, dove "errori di file" non sono "eccezionali"

Il tuo "return ResultCode.Fail" gestisce casi minimi come quello, in cui puoi isolare la parte del programma in cui vuoi disattivare la gestione delle eccezioni.

D'altra parte, quando ti ritrovi a fasciare ogni singola linea in un blocco try-catch separato, è il momento di trovare una lingua diversa, non il tempo per crearla da solo.

risposta data 18.02.2014 - 05:26

fonte

0

Se lo fai, avrai creato un sistema estremamente complesso ed efficacemente non verificabile; il numero di possibili comportamenti di sistema aumenta esponenzialmente con il numero di questo tipo di impostazioni di configurazione. Di conseguenza, di solito non funzionerà.

Ma al rialzo, gli errori introdotti saranno, in linea di principio, sempre riparabili da un'altra modifica del file di configurazione. E in alcuni casi le impostazioni di configurazione corrette da modificare potrebbero essere rilevabili entro pochi giorni dall'indagine ...

risposta data 22.02.2014 - 15:59

fonte

Leggi altre domande sui tag design-patterns exception-handling configuration

Utilizzare un modello per ottenere un comportamento alternativo? Come migliorare il codice dopo aver conosciuto molte lingue? [chiuso]

score 8 · Accepted Answer

Secondo me, il modo migliore per gestire le eccezioni in C # è lo stesso esposto in questo articolo: link (cerca "Gestione eccezioni")

Si noti che lo stesso modello può essere utilizzato per Java: link

Il concetto più importante è:

"(almost)Never handle exceptions locally"

Questo è il modo più semplice e più pulito per gestire le eccezioni sia in Java che in C #. Nel tuo caso cogli l'eccezione ogni volta che può succedere e poi configura come gestirli, ho ragione? Ora non è un suggerimento che dovresti centralizzare la gestione delle eccezioni elsewere? Invece di ripetere lo stesso modello try - catch -handleExceptionInAConfigurableWay - throw ogni volta. Personalmente non vedo alcun punto nella configurazione di un FailureMode globale per gestire le eccezioni, se hai un ApplicationFilter come quello nel primo articolo, e vuoi cambiare il modo in cui viene gestita l'eccezione, basta cambiare il comportamento di% co_de metodo% template.

Risultato:

+1 : la gestione effettiva delle eccezioni dovrebbe essere centralizzata

-10 : non in questo modo!

Ovviamente non è possibile lanciare sempre un'eccezione e gestirla in un unico punto "filtro applicazione". A volte hai qualche operazione da fare in caso di eccezioni (es. Rollback di una transazione), o in ogni caso (es. Un file aperto da chiudere infine block), ma in qualsiasi altra situazione, se devi solo loggare lo stacktrace di eccezione o inserire un messaggio di errore in alcune GUI, quindi lanciare l'eccezione e gestirla in un unico punto globale.

L'utilizzo di Eccezioni come parte della tua logica aziendale non è mai stato un buon esempio e l'errore epico dell'eccezione controllata di Java ne è una prova.