Il capo della mia azienda dice che devo scrivere tutto, cioè TUTTO il mio codice all'interno delle dichiarazioni Try-catch. Ora, posso capire l'approccio 'meglio prevenire che curare' qui, ma non è troppo volgare pensare che ci sarà un'eccezione quando le etichette saranno create, la posizione della forma è impostata. ci sono stati casi in cui eccezioni in operazioni così semplici.
My company head says that I must write all, i.e. ALL my code within Try-catch statements.
Bene, questo è un po 'esagerato e porta solo a un codice rumoroso. Quali sono i vantaggi di avere tutto il codice (ogni metodo, ad es.) Scritto con un gestore catch try? Ti dice solo che c'è un errore da correggere nella maggior parte dei casi. Spesso, l'eccezione può e deve essere evitata in primo luogo.
Un'occhiata alla traccia dello stack è in gran parte sufficiente per rivelare la causa nel codice, anche se il metodo di errore non esegue il blocco stesso. Ci sono momenti in cui gli sviluppatori corrompono le tracce di stack in eccezioni, ma è molto più frequente quando si hanno molti e molti gestori di eccezioni. Come qualsiasi cosa: un po 'è buono, ma troppo è veleno.
La gestione delle eccezioni è davvero piuttosto semplice:
Eccezioni catch
Se ci pensi, allora c'è sempre solo un posto che è buono per gestire un'eccezione. E quindi il conduttore dovrebbe essere in quel posto.
Molte eccezioni non dovrebbero nemmeno essere gettate in primo luogo, quindi non costruire le tue strutture di controllo intorno alla gestione delle eccezioni, piuttosto cerca di evitare il possibile verificarsi di eccezioni quando e dove possibile.
Ricordati di andare in crash presto quando le cose vanno (irreparabilmente) in modo sbagliato. Mettere tutto il codice nelle dichiarazioni try-catch è assurdo, ma non dimenticare di segnalare e registrare TUTTE le eccezioni.
but isn't it too chicken-hearted to think that there will be an exception when the Labels are created, form's position is set. has there been instances where Exceptions in Such simple operations.
Assolutamente sì! C'è sempre un modo in cui le cose vanno male che non hai previsto. E "dal cuore di pollo" è un'espressione ridicola da usare in questo contesto; lo sviluppo del software non significa provare il tuo machismo ignorando potenziali problemi.
Che è una domanda valida è se è utile perché le eccezioni vengano catturate nel punto in cui gli standard di codifica dicono che devono farlo. La tua affermazione dice che devi provare / catturare il blocco attorno a ogni corpo del metodo, e questo è davvero assurdo perché spesso non puoi fare qualcosa di utile con un'eccezione, e questo è in realtà il punto di eccezione: puoi scegliere di lasciarli propagare lo stack di chiamate da trattare nel punto appropriato.
Vorrei girare questo il contrario. Sì, come regola generale la gestione delle eccezioni è una buona cosa, ma puoi effettivamente gestire ogni possibile eccezione in modo ragionevole nel punto in cui viene catturata? A volte, in particolare se non stai scrivendo software critico, è meglio semplicemente crash e masterizzazione in modo controllato a metà strada quando le cose vanno terribilmente storte.
Se non puoi essere sicuro al 100% che puoi gestire ogni singola eccezione che potrebbe essere catturata, probabilmente stai meglio scrivendo una specie di gestore di eccezioni generale, avvolgendo il ciclo principale del programma in esso - la meccanica esatta di come Questo ovviamente dipende dal linguaggio in cui stai lavorando. Lì, registra quanti più dettagli possibile sull'eccezione, salva lo stato del programma (da qualche parte altro rispetto a qualsiasi archivio dati al quale l'utente sta attualmente lavorando contro - ricorda, potrebbe essere tutto corrotto a questo punto), e così via. Quindi, riformulare l'eccezione e lasciare che sia il sistema operativo a gestirlo come riterrà opportuno. In questo gestore eccezioni catch-all, essere preparato per un errore catastrofico . Quindi, quando il programma viene riavviato, controlla se questo stato è in qualche modo utile e ripristina ciò che può essere salvato se lo è; e possibilmente offrire all'utente di inviare una segnalazione di bug a te.
Nel complesso, l'utilizzo di try / catch è deprecato, perché il blocco catch è così costoso dal punto di risorse. L'utilizzo / rilevamento dell'utilizzo mi ricorda gestione dei rischi . La gestione dei rischi ha due dimensioni:
Ora, se esci di casa, un pianostrong ti cade in testa da qualche parte mentre è così improbabile che accada (forse lo 0,001%), ma può ucciderti.
La gestione delle eccezioni è così. Prova a bloccare non è costoso. Ma il blocco catch è molto costoso, perché è necessario creare una tabella di stack trace e fare altre cose. Pertanto, nel prendere una decisione sui blocchi try / catch, dovresti considerare quante volte hai colpito il blocco catch. Se tra 10.000 usi, lo colpisci solo 1 volta, quindi usalo. Ma se è un modulo e l'utente probabilmente non lo riempie correttamente il 50% delle volte, allora dovresti evitare di mettere in azione un blocco try / catch.
Nei luoghi in cui la probabilità di verificarsi di un'eccezione è elevata, si consiglia di utilizzare i blocchi if {} else {} per evitare il verificarsi di un'eccezione.
Ad esempio, dove vuoi dividere due numeri, invece di 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 è l'odore del codice e il lavoro scadente.
Personalmente non sopporto eccezioni, sono MOLTO, MOLTO, MOLTO difficili da gestire correttamente. E provare a eliminare i dati corrotti è MOLTO, MOLTO, MOLTO difficile!
Se non chiami ogni funzione 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 su ogni punto di uscita. Le eccezioni sono HARD!
L'unica cosa buona delle eccezioni è che se non le prendi, l'app si arresta in modo anomalo in caso di comportamento imprevisto.
Leggi altre domande sui tag code-reviews