È "cattivo" utilizzare try-catch per il controllo del flusso in .NET?

Question

Ho appena trovato in un progetto:

try 
{ 
    myLabel.Text = school.SchoolName; 
} 
catch 
{ 
    myPanel.Visible = false; 
} 

Voglio parlare con lo sviluppatore di scritto questo, dicendo che incorrere l'eccezione null (perché school potrebbe teoricamente essere nullo, non myLabel) sarebbe praticamente rendere il computer beep three times and sleep for two seconds . Tuttavia, mi chiedo se sto dimenticando erroneamente la regola al riguardo. Ovviamente, questo non è l'uso previsto per try/catch, ma è così male perché sfida l'intenzione, o cattiva a causa di considerazioni sulle prestazioni? Mi sento come se fosse solo brutto, ma voglio dire più di "questo è veramente cattivo".

Answer 1

Non si dovrebbero usare eccezioni per il flusso di controllo semplicemente perché è una cattiva progettazione. Non ha senso. Le eccezioni sono per casi eccezionali, non per il flusso normale. Le prestazioni probabilmente non saranno un problema in questa situazione, perché per la maggior parte delle moderne applicazioni su hardware moderno, è possibile generare eccezioni per tutto il giorno e l'utente non noterà un impatto sulle prestazioni. Tuttavia, se si tratta di un'applicazione ad alte prestazioni che elabora un sacco di dati o fa un sacco di lavoro, allora sì, le prestazioni sarebbero un problema.

Answer 2

Penso che questo sia male perché codifica contro un'eccezione per uno e inoltre erediterà un sovraccarico non necessario. Le eccezioni dovrebbero essere prese solo se saranno gestite in un modo specifico.

Le eccezioni devono essere rilevate in modo specifico per i casi eccezionali che non è possibile prevedere, in questo caso è un semplice controllo per vedere se la scuola può essere nullo, infatti è previsto che la scuola possa essere nullo (poiché l'etichetta è impostata Niente). Se la scuola era nullo e non avrebbe dovuto essere, dovrebbe gettare la propria ArgumentNullException.

Answer 3

Non mi piace mai utilizzare le eccezioni per il controllo di flusso. Le eccezioni sono costose ed è difficile determinare quale sia il flusso effettivo di un programma con eccezioni generate per raggiungere altri posti nel codice. Per me è come usare GoTo. Questo non significa che dovresti evitare le eccezioni, ma piuttosto un'eccezione dovrebbe essere proprio questa, un'eccezione a ciò che dovrebbe normalmente accadere nel programma.

Penso che una parte peggiore del codice, è che non fa nemmeno nulla con l'eccezione. Non vi è alcuna registrazione o spiegazione del motivo per cui viene lanciata l'eccezione.

Answer 4

Hai assolutamente ragione che questo è male. È male perché sfida l'intenzione e perché fa male alle prestazioni.

Mi rendo conto che c'è spazio per diversi stili di programmazione, ma personalmente, penso che anche se questo funziona, e posso vedere cosa il codice sta tentando di fare, danneggia anche la leggibilità e la chiarezza del codice, il che rende molto più difficile da seguire per i programmatori di manutenzione. Un'istruzione if è molto più appropriata qui.

Answer 5

eccezioni lancio ha un impatto negativo sulle prestazioni, vedere http://msdn.microsoft.com/en-us/library/ms229009(VS.80).aspx

Answer 6

eccezioni non incorrere in spese generali di esecuzione, ma è probabilmente irrilevante qui. Ci sarà una differenza nell'esecuzione nel debugger, ma i binari compilati dovrebbero funzionare più o meno alla stessa velocità.

Informa il tuo sviluppatore che ogni scimpanzè può creare codice che la macchina può leggere. Il buon codice è scritto per gli esseri umani, non per le macchine. Se un'eccezione null è l'unica cosa di cui ti preoccupi, allora è probabilmente un bug nel codice dell'utente - nessuno dovrebbe mai provare ad assegnare null a qualcosa in quel modo. Utilizzare invece un'istruzione Assert().

Answer 7

A mio parere questo è povero perché potrebbe essere reso molto più chiaro con un'istruzione if:

if (school != null) { 
    myLabel.Text = school.SchoolName; 
} 
else { 
    myPanel.Visible = false; 
} 

che certamente evitare di usare la manipolazione inutilmente eccezione e rendere il codice che significa molto evidente.

Answer 8

Controlla questo post in "Perché non utilizzare le eccezioni come regolare flusso di controllo?"

Answer 9

Sono d'accordo con tutti qui - è un'idea orribile.

Ci sono alcuni casi in Java (penso che siano per lo più scomparsi ora, ma potrebbero essercene ancora alcuni in librerie esterne) in cui è stato richiesto di rilevare un'eccezione per alcuni casi "non-eccezione".

In generale, quando si scrive codice di libreria (beh, qualsiasi classe in effetti), evitare di utilizzare eccezioni per TUTTO ciò che potrebbe essere evitato. Se è possibile che un campo nome non sia impostato e ciò dovrebbe causare un'eccezione in un metodo write(), assicurati di aggiungere un metodo isValid() in modo che tu in realtà non debba catturare l'eccezione intorno alla scrittura per sapere c'è un problema.

(Supplemento del codice Java errato): questo "buono" stile di programmazione elimina virtualmente qualsiasi necessità di eccezioni controllate in Java e le eccezioni controllate in Java sono Suck.