Come implementare la gestione delle eccezioni di livello superiore?

Question

Di recente ho dovuto sviluppare un modulo aggiuntivo per un servizio esistente sviluppato da un collega. Aveva messo un blocco try / catch nella funzione di lavoro principale per catturare tutte le eccezioni non confuse che si propagavano a questo livello, registrandole insieme con le informazioni di traccia dello stack, ecc .:

try
{
    // do main work
}
catch(Exception ex)
{
    // log exception info
}

Mentre questo rende il programma molto stabile (come in "improbabile crash"), lo odio perché quando sto testando il mio codice, non vedo le eccezioni causate da esso. Ovviamente posso guardare il registro delle eccezioni e vedere se ci sono nuove voci, ma preferisco di gran lunga il feedback diretto di ottenere l'eccezione nel momento in cui viene generata (con il cursore sulla riga destra nel codice, per favore).

Ho rimosso questo livello superiore try / catch almeno mentre stavo ancora programmando e testando. Ma ora il mio compito è finito e devo decidere se rimetterlo o meno per il rilascio. Penso che dovrei farlo, perché rende il servizio più stabile e il punto è che funziona in background senza bisogno di supervisione. D'altra parte ho letto che si dovrebbero chiamare solo eccezioni specifiche (come in IoException ), non genericamente Eccezione .

Qual è il tuo consiglio su questo problema?

A proposito, il progetto è scritto in C #, ma sono anche interessato a risposte per linguaggi non .NET.

Answer 1

Rimettilo.

L'eccezione dovrebbe essere rilevante solo durante il test. Altrimenti non ha senso aprirlo all'utente.

La registrazione va bene.

È inoltre possibile utilizzare il simbolo DEBUG definito da Visual Studio per le build di debug come flag.

    ...
    } catch( Exception e ) { 
#if DEBUG
          throw;
#else
          log as usual 
#endif
    }

Quindi la prossima volta che è necessaria una modifica, il flag di debug dovrebbe essere impostato su true e verrà visualizzata l'eccezione.

Answer 2

In qualsiasi applicazione Java, vuoi quasi sempre definire un gestore di eccezioni per eccezioni non rilevate con qualcosa del genere:

Thread.setDefaultUncaughtExceptionHandler( ... );

dove l'oggetto che catturerà queste eccezioni non rilevate registrerà almeno l'errore in modo da avere la possibilità di conoscerlo. Altrimenti, non vi è alcuna garanzia che ti verrà persino notificato che un thread ha preso un'eccezione, a meno che non sia il tuo thread principale.

Oltre a ciò, la maggior parte dei miei thread ha un tentativo / cattura in cui prenderò RunnableException (ma non Error ) e registrerò ... I thread moriranno quando ciò accade, altri accederanno e ignoreranno, altri mostreranno un reclamo all'utente e lasceranno che l'utente decida, a seconda delle esigenze dell'applicazione. Questo try / catch è alla radice del thread, nel metodo Runnable.run () o equivalente. Poiché try / catch è alla radice del thread, a volte non è necessario disabilitare questo catch.

Quando scrivo in C #, scrivo in modo simile. Ma tutto dipende dalla necessità dell'applicazione. L'eccezione è quella che corromperà i dati? Bene, allora, non catturarlo e ignorarlo. SEMPRE registralo, ma poi Lascia che l'applicazione muoia. La maggior parte delle eccezioni non è di questo tipo, tuttavia.

Answer 3

Idealmente, si desidera gestire un'eccezione il più vicino possibile al luogo in cui si è verificata, ma ciò non significa che un gestore di eccezioni globale sia una cattiva idea. Soprattutto per un servizio che deve rimanere attivo a tutti i costi. Vorrei continuare quello che hai fatto. Disabilitalo durante il debug ma lascialo in posizione per la produzione.

Tieni presente che dovrebbe essere usato come rete di sicurezza. Cerca ancora di cogliere tutte le eccezioni prima che si elevino così lontano.

Answer 4

L'impulso di cogliere tutte le eccezioni e rendere il programma "stabile" è molto forte e l'idea sembra davvero molto allettante per tutti. Il problema, come sottolineato, è che questo è solo uno stratagemma e il programma potrebbe benissimo essere difettoso e peggio, senza indicazioni di guasti. Nessuno controlla regolarmente i registri.
Il mio consiglio sarebbe di provare a convincere l'altro sviluppatore a fare test approfonditi e quindi a implementarlo in produzione senza il fermo esterno.

Answer 5

Se vuoi vedere l'eccezione quando si verifica, in Visual Studio puoi andare al menu DEBUG, selezionare EXCEPTIONS e puoi dire al debugger di rompere non appena viene generata un'eccezione. Puoi persino scegliere il tipo di eccezioni. :)