Devo lasciare un'interruzione irraggiungibile in un caso in cui lancio un'eccezione?

Question

È sciocco da parte mia lasciare dichiarazioni di interruzione irraggiungibili in un caso che genera comunque un'eccezione? La parte difensiva di me vuole lasciarla lì nel caso in cui la logica cambi. Un'altra parte di me non vuole che altri sviluppatori vedano avvisi del compilatore sul mio codice ("Rilevato codice non raggiungibile").

switch (someInt) 
{ 
    case 1: 
     // Do something 
     break; 
    case 2: 
     // Do something else 
     break; 
    case 3: 
     // Oh, we don't use threes here! 
     throw new Exception("Business rules say don't use 3 anymore"); 
     break; // Unreachable...until the fickle business rules change... 
    default: 
     throw new Exception("Some default exception"); 
     break; // Unreachable...until...well, you get the idea. 
} 

Cosa fare?

UPDATE

vedo alcune risposte dicendo che la rimozione del lancio ad una data successiva causerebbe un errore di compilazione. Tuttavia, semplicemente rimuovendo (o commentando) il lancio senza interruzioni, i casi potrebbero essere impilati. Non sto dicendo che è uno scenario probabile, ma ... beh, la programmazione difensiva riguarda la lotta solo a possibili scenari?

Answer 1

I' d rimuoverli. Diversi motivi:

• Tu non li servono al momento
• Vedendo un sacco di avvertimenti mi fa sempre nervoso come si possono perdere le avvertenze reali nel rumore proveniente da questo tipo di avvertimento (ammesso che abbiate avvertono come errore off).

Answer 2

La parte difensiva di me vuole lasciarlo lì nel caso in cui la logica cambi.

Quale logica è esattamente soggetta a modifiche qui? Ciò che accade quando viene lanciata un'eccezione è documentato abbastanza bene. E penso che tu possa essere ragionevolmente sicuro che nessuna revisione successiva alla C# avrà effetto su un cambiamento improvviso di "tutti i programmi scritti finora non funzionano più".

Anche se non ci sono avvisi del compilatore, il codice ridondante non è una buona cosa a meno che non ci sia la possibilità che il codice possa entrare in gioco impedendo bug durante la manutenzione di routine, che in questo caso non possiamo ragionevolmente dire che tale possibilità esiste.

Answer 3

La parte difensiva di me vuole lasciarla lì nel caso in cui la logica cambi.

Beh, se si rimuove il throw e dimentica di aggiungere un break il compilatore vi farò sapere.

Non vedo alcuna ragione per la pausa di essere lì. È ridondante e si innescherà comunque un avvertimento, quindi lo rimuoverei. Non c'è una buona ragione per lasciare il codice inutile a ingombrare la tua logica.

Answer 4

Lo rimuoverei.

E si libera delle avvertenze, e anche se la logica dovesse cambiare e la deroga da rimuovere, che ci si riceve un errore del compilatore dice che una rottura deve essere aggiunto indietro nel.

Answer 5

Ignorando alcuni avvisi del compilatore, si rinforza il cattivo comportamento di ignorare qualsiasi avviso del compilatore. A mio parere, questo è un rischio maggiore rispetto a qualsiasi vantaggio ottenuto lasciando le dichiarazioni break in.

EDIT: ho rimosso il mio punto originale sulla compilatore ti costringe a mettere le dichiarazioni break indietro nel se i throw dichiarazioni dovevano essere rimossi. Come ha sottolineato Payo, in alcuni casi, il compilatore non lo farebbe. Semplicemente combinerebbe il caso con quello sottostante.

Answer 6

Personalmente, non lascerei mai il codice irraggiungibile nel codice di produzione. Va bene per i test, ma non lasciarlo come tale.

Non lo faresti mai?

public void MyMethodThatThrows() 
{ 
    throw new Exception(); 
    return; // unneeded 
} 

quindi perché mantenere lo break?

Answer 7

Non lo "nascondere" nello switch. Vorrei lanciare il ArgumentExceptions il prima possibile. Ciò evita effetti collaterali ed è anche più trasparente.

Qualcuno potrebbe aggiungere il codice prima che l'interruttore ad un certo punto che utilizza someInt anche se è 3.

Ad esempio:

public void SomeMethod(int someInt) 
{ 
    if (someInt == 3) 
     throw new ArgumentException("someInt must not be 3", "someInt"); 

    switch (someInt) 
    { 
     // ... 
    } 
} 

Answer 8

Vorrei che le mie fonti di progetto erano così fresco e guai-less, che Dovrei pensare a casi minori di programmazione difensiva :)

Voglio dire ci sono così tante insidie ​​nello sviluppo del software - COM e Interop, Sicurezza/Permessi e Autenticazione, Certificati, che ... gosh , non posso dirti come molto codice dovrei scrivere per difendermi dalle riprese in piedi.

Basta rimuovere questa interruzione, perché è ridondante, è fonte di confusione per i borsisti che sanno che 'caso' dovrebbe terminare con break o return e dovrebbe diventare ovvio per gli utenti che non lo sanno.

Answer 9

MSDN C# Reference afferma: "Un'istruzione di salto come un'interruzione è necessaria dopo ogni blocco di casi, incluso l'ultimo blocco, sia che si tratti di un'istruzione case o di un'istruzione predefinita."

Quindi, il "lancio" non costituisce una "istruzione di salto"? Penso che lo faccia. Pertanto, "break" non è richiesto e il problema "irraggiungibile" scompare. :)