Cosa fare con le eccezioni derivanti dai bug?

Per le eccezioni di tipo 2, è necessario chiudere il programma. Non è necessario lasciare che il runtime mostri il proprio errore, è possibile rilevare l'errore al livello più alto e mostrare il proprio messaggio (e registrare l'eccezione originale da qualche parte). Ma non dovresti permettere al programma di continuare.

Poiché il programma si trova in uno stato che "non dovrebbe accadere", non si ha idea di quale sia la causa del problema e della quantità di stato del programma che è corrotta. Non c'è modo di recuperare con garbo da un tale problema, e ignorarlo causerà più problemi lungo la linea poiché stai già elaborando dati corrotti.

Ci sono alcuni casi in cui è possibile recuperare da un errore di tipo 2. Se si verifica in un sottosistema isolato, in cui è possibile eliminare tutti gli output dal sottosistema e non è fondamentale per la continuazione del programma. Supponi di avere un componente di controllo ortografico in un editor. Un errore di tipo 2 può essere recuperato semplicemente disabilitando questo componente, o magari riavviando il componente. Ma questo è possibile solo con sottosistemi che sono attentamente progettati per essere isolati e non critici.

exceptions that you wouldn't expect to happen if you have written your program correctly

Dipende molto dalla tua applicazione.

Se particolare, se si tratta di un'applicazione "critica", potresti teoricamente isolare tutte le principali unità di lavoro in transazioni. Se si verifica un'eccezione all'interno di una transazione, è necessario riprovare e ripristinare / rollback per le opzioni. Quello che fai specificamente dipende dallo scopo della tua applicazione.

Per elementi meno critici, prendi tutte le eccezioni a livello globale: dai un messaggio amichevole all'utente e offri di segnalare l'eccezione prima di uscire dal programma.

Risposta principale / breve

Dipende dal tuo programma, dalle esigenze di detto programma e dal livello critico di detto programma.

Risposta leggermente più lunga

Una buona soluzione "shotgun-catch-all" è vedere se il linguaggio di programmazione del tuo programma ha una sorta di metodo o classe di gestione degli errori di default che TUTTI gli errori passano e basta sovrascriverli per rilevare l'errore, registrarlo / segnalarlo allo sviluppatore, quindi uccidere il programma.

Risposta lunga

Se sviluppi il tuo programma in alcune mode (cioè moduli isolati e incapsulati) puoi, teoricamente (perché è pericoloso andare avanti se viene trovato un errore), resettare quel modulo e continuare / riprovare su quel modulo.

Il più grande svantaggio di questo è che speri che la sezione del problema (qualunque cosa sia) si risolverà da sola dopo mille iterazioni. È quasi come accettare la pazzia come una soluzione (continua a cercare di aspettarti un risultato diverso) ... ma per alcuni programmi, DEVE essere fatto perché sono così mission critical (pensa a programmi usati in situazioni mediche ... NON POSSONO fallire e deve andare avanti indipendentemente da cosa).

Ricorda che la soluzione "accetta follia" può anche presentare all'utente un programma senza fine (cioè non possono procedere o il computer si blocca in un ciclo cercando di risolvere il programma).

È un'arma a doppio taglio, sì puoi progettare il programma per andare avanti e resettare la sezione del problema e questo ha il potenziale di introdurre errori in seguito a causa di dati corrotti e fare in modo che l'utente "ripeti" il processo fino a quando non viene risolto .

D'altro canto, uccidere il programma per ogni errore può far sembrare il programma instabile o mal progettato anche se è colpa dell'utente causare il crash del programma (cioè l'arte della convalida dell'input dell'utente) o può causare lo sviluppatore iniziare a diventare pigri con correzioni di bug (perché vengono bombardati) usando cose come blocchi try-catch ovunque (l'ho visto su un progetto una volta ... quasi tutti i metodi sono stati provati).

Come la mia prima linea, dipende molto dal tuo programma.

Una cosa, quando viene rilevato un errore di programmazione (ad esempio perché viene lanciata un'eccezione) durante lo sviluppo, lo sviluppatore deve essere informato, in modo che il bug nel codice sia corretto. Quindi assicurati che durante lo sviluppo ti venga notificato quando si verifica un errore di questo tipo.

Se ciò accade nelle mani di un cliente, ci sono alcune considerazioni. Uno importante: NON MAI MAI consentire una situazione in cui l'utente è bloccato. Quindi, se leggi un file come parte del normale funzionamento, e questo fallisce e la tua app si arresta in modo anomalo, l'app viene nuovamente avviata e legge lo stesso file e fallisce nuovamente e l'app viene riavviata e così via, quindi l'utente ha un problema serio Assicurati che questo tipo di cose non avvenga - se la lettura di questo file fallisce e sai che fallirà di nuovo se proverai di nuovo, allora potresti cancellare quel file.

Oltre a ciò, in genere hai due scelte: annulla l'operazione dell'utente che ha causato il problema o esci dal programma. Se l'operazione ha apportato modifiche permanenti parziali, hai un problema. Se sospetti che il bug possa aver causato danni, fai ciò che devi fare in modo che il bug non diventi permanente. Ad esempio, se un cliente ha ordinato cinque articoli e la creazione di una fattura presenta un'eccezione all'articolo 2, non si desidera inviare solo una fattura per quattro articoli, è preferibile annullare l'intera operazione. Se sospetti che il danno non notato abbia provocato il tuo bug, potresti prendere in considerazione l'uscita dall'applicazione.

Non esiste una regola semplice e generale.

Alcune lingue hanno un meccanismo aggiuntivo di asserzioni . Mentre le eccezioni indicano casi eccezionali, come un errore di rete durante un trasferimento, o un errore nel leggere un file a causa di errate autorizzazioni impostate, le asserzioni non riuscite indicano i bug nell'applicazione stessa.

Sebbene le eccezioni possano essere gestite, ad esempio riprovare il trasferimento in caso di errore di rete o chiedere all'utente di correggere le autorizzazioni su un file o non gestito, portando ad un gestore di eccezioni globale da attivare, i fallimenti di asserzione sono sempre non gestiti, cioè sono gestiti solo a livello globale.

Di conseguenza, quando tale asserzione fallisce:

• O lascia che l'applicazione si arresti e fai affidamento sul sistema operativo per informarti sul problema,

• Oppure registri il problema e fai arrestare l'applicazione,

• Oppure registra il problema e mostra un messaggio di scuse all'utente.

La fonte dell'errore non ha importanza. La gestione delle eccezioni è incentrata sul recupero: cosa puoi fare per continuare a ridurre al minimo il danno e l'inconverità dell'utente.

In generale, il recupero richiede generalmente una delle due forme, interrompendo l'azione o tentando un'azione alternativa che raggiunga lo stesso obiettivo.

La registrazione degli errori dovrebbe essere eseguita in entrambi i casi.