Perché dovrei scrivere tutte le dichiarazioni all'interno di Try-Catch?

Il mio capo dell'azienda dice che devo scrivere tutto, cioè TUTTO il mio codice all'interno delle dichiarazioni Try-catch. Ora riesco a capire l'approccio "meglio prevenire che curare" qui, ma non è forse troppo sincero pensare che ci sarà un'eccezione quando le etichette saranno create, la posizione del modulo è impostata. ci sono stati casi in cui Eccezioni in operazioni così semplici.

Il mio capo dell'azienda dice che devo scrivere tutto, cioè TUTTO il mio codice all'interno delle dichiarazioni Try-catch.

Bene, questo è un po 'esagerato e porta solo a un codice rumoroso. Quali sono i vantaggi di avere tutto il codice (ad esempio ogni metodo) scritto con un gestore try catch? Ti dice solo che c'è un errore da correggere nella maggior parte dei casi. Spesso, l'eccezione può e dovrebbe essere evitata in primo luogo.

Uno sguardo alla traccia dello stack è per lo più sufficiente per rivelare la causa nel codice, anche se il metodo di errore non esegue il catch stesso. Ci sono momenti in cui gli sviluppatori corrompono le tracce dello stack in eccezioni, ma questo è molto più spesso il caso in cui ci sono molti gestori di eccezioni. Come qualsiasi cosa: un po 'va bene, ma troppo è veleno.

La gestione delle eccezioni è davvero piuttosto semplice:

Eccezioni di cattura

• ogni volta che hai bisogno di un'azione speciale come reazione all'eccezione
• ogni volta che un'eccezione lascia il programma in uno stato incoerente se non gestita

Se ci pensate, allora c'è sempre solo un posto che è buono per gestire un'eccezione che si verifica. E quindi il gestore dovrebbe trovarsi in quel posto.

Molte eccezioni non dovrebbero nemmeno essere lanciate in primo luogo, quindi non costruire le tue strutture di controllo attorno alla gestione delle eccezioni, piuttosto cerca di evitare il possibile verificarsi di eccezioni quando e dove possibile.

Ricorda di schiantarti presto quando le cose vanno (irreparabilmente) sbagliate. Inserire tutto il codice nelle istruzioni try-catch è assurdo, ma non dimenticare di segnalare e registrare TUTTE le eccezioni.

ma non è troppo sincero pensare che ci sarà un'eccezione quando si creano le etichette, la posizione del modulo è impostata. ci sono stati casi in cui Eccezioni in operazioni così semplici.

Assolutamente si! C'è sempre un modo in cui le cose vanno male che non avevi previsto. E "dal cuore di pollo" è un'espressione ridicola da usare in questo contesto; lo sviluppo del software non consiste nel provare il tuo machismo ignorando potenziali problemi.

Qual è una domanda valida è se è utile rilevare le eccezioni nel punto in cui gli standard di codifica dicono che devono. La tua affermazione dice che devi avere un blocco try / catch attorno a ogni metodo metodo, e questo è davvero assurdo perché spesso non puoi fare immediatamente qualcosa di utile con un'eccezione, e questo è in realtà il punto intero delle eccezioni: che puoi scegliere di lasciarli propagare lo stack di chiamate da trattare nel punto appropriato.

Vorrei ribaltare il contrario. Sì, come regola generale la gestione delle eccezioni è una buona cosa, ma puoi effettivamente gestire ogni possibile eccezione in modo sensato nel punto in cui viene rilevata? A volte, in particolare se non stai scrivendo software mission-critical, è meglio semplicemente schiantarsi e bruciare in un modo controllato a metà strada quando le cose vanno terribilmente male.

Se non puoi essere sicuro al 100% di poter gestire ogni singola eccezione che potrebbe essere rilevata, probabilmente stai meglio scrivendo una sorta di gestore di eccezioni generale, avvolgendo il ciclo principale del programma in esso - l'esatta meccanica di come farlo ovviamente dipende dalla lingua in cui stai lavorando. Lì, registra quanti più dettagli possibile sull'eccezione, salva lo stato del programma (in un posto diverso da qualsiasi archivio di dati su cui l'utente sta attualmente lavorando - ricorda, a questo punto potrebbe essere tutto corrotto ), e così via. Quindi, ripeti l'eccezione e lascia che il sistema operativo la gestisca come ritiene opportuno. In questo gestore di eccezioni onnicomprensivo, prepararsi per un errore irreversibile. Quindi, quando il programma viene riavviato, controlla se questo stato è in qualche modo utile e ripristina ciò che può essere recuperato se lo è; e possibilmente offrire all'utente di inviarti una segnalazione di bug.

Nel complesso, l'utilizzo di try / catch è deprecato, poiché il blocco catch è così costoso dal punto di vista delle risorse. L'utilizzo di Try / catch mi ricorda la gestione del rischio . La gestione dei rischi ha due dimensioni:

1. La probabilità che si verifichi un rischio
2. Il danno che può avere

Ora, se esci di casa, un piano che ti cade in testa da qualche parte mentre è così improbabile che accada (forse 0,001%), ma può ucciderti.

La gestione delle eccezioni è così. Try block non è costoso. Ma il blocco catch è davvero costoso, perché deve creare una tabella di stack stack e fare altre cose. Pertanto, nel prendere una decisione sui blocchi try / catch, dovresti considerare quante volte probabilmente colpisci il blocco catch. Se tra 10.000 usi, lo colpisci solo 1 volta, quindi utilizzalo. Ma se si tratta di un modulo e l'utente probabilmente non lo riempie correttamente per il 50% di volte, allora dovresti evitare di mettere in atto un blocco try / catch.

Nei luoghi in cui la probabilità di verificarsi di un'eccezione è elevata, si consiglia di utilizzare i if {} else {}blocchi per evitare il verificarsi di eccezioni. Ad esempio, dove si desidera dividere due numeri, anziché scrivere:

try
{
    int result = a/b;
}
catch (DivisionByZeroException ex)
{
    // Showing a message here, and logging of course.
}

dovresti scrivere:

if (b == 0)
{
    int result = a/b;
}
else
{
    // Showing a message to user to change the value of b, etc.
}

Dovresti usare try-catch quando appropriato, ma per favore oh, per favore, non catturare tutte le eccezioni e nemmeno registrarlo. A quel punto è odore di codice e lavoro scadente.

Personalmente non sopporto le eccezioni, sono MOLTO, MOLTO, MOLTO difficili da gestire correttamente. E cercare di decifrare i dati corrotti è MOLTO, MOLTO, MOLTO difficile!

http://blogs.msdn.com/b/mgrier/archive/2004/02/18/75324.aspx

http://blogs.msdn.com/b/oldnewthing/archive/2004/04/22/118161.aspx

http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx

http://www.joelonsoftware.com/items/2003/10/13.html

Se non chiami tutte le funzioni come:

try
{
    TrivialFunction();
}
catch(TypeAException)
{
    //MaybeFix
}
catch(TypeBException)
{
    //MaybeFix
}
catch(TypeCException)
{
    //NO FIX - CORRUPT DATA
}
catch(TypeDException)
{
    //NO FIX - UNKNOWN STATE
}
catch(OutOfMemoryException)
{
    //Try to fix this one! Destructors might allocate on their own ;)
}
catch(Exception)
{
    //Nothing to see here, move on, everything is OK ;)
}

Non è possibile ripulire correttamente ogni punto di uscita. Le eccezioni sono DURE!

L'unica cosa positiva delle eccezioni è che se non le prendi, l'app si arresta in modo imprevisto.