2010-04-30 9 views
11

Ho per esempio un try/catch nel mio metodo:Exit try/catch per evitare che codice dopo dall'essere corsa

} 
    catch (OurCustomExceptionObject1 ex) 
    { 
     txtErrorMessage.InnerHtml = "test 1"; 
    } 
    catch(OurCustomExceptionObject2 ex) 
    { 
     txtErrorMessage.InnerHtml = "test 2"; 
    } 
    catch (OurCustomExceptionObject3 ex) 
    { 
     txtErrorMessage.InnerHtml = "test 3"; 
    } 

    ... rest of code here is being executed after the try/catch 

Non voglio il resto del codice da eseguire se una delle eccezioni sono presi. Sto gestendo le eccezioni. Ho sentito che non usare Exit Try per qualche motivo. È vero, è brutto farlo? È questo il modo giusto per fermare l'esecuzione del codice da allora in poi la dichiarazione di cattura?

+1

'Exit Try' esiste solo in VB.NET. Non si applica a C#. In C#, la caratteristica della lingua corrispondente sarebbe 'break', ma è illegale in un blocco' try..catch..finally'. La prossima cosa migliore sarebbe 'return', che non fa lo stesso, ma è una cosa perfettamente legale da fare. – stakx

+0

@stakx 'break' non è illegale nel blocco' catch'. Può essere usato per uscire dal giro. –

risposta

30

O return nel catch-block, rilanciare l'eccezione o spostare il codice da sotto il try-block all'interno del try-block.

+0

Precisamente quello che stavo per rispondere – BlitzKrieg

+2

Sì. E penso che spostare il codice sia l'approccio migliore in questo caso. Se vuoi impedire al codice di continuare quando c'è un'eccezione, non fare nulla. Un'eccezione interrompe già il flusso di esecuzione. Basta circondare il tutto con un try-catch se vuoi gestire anche l'operazione. Sebbene si tratti di un metodo, racchiuderei la chiamata al metodo piuttosto che il corpo del metodo, quindi le eccezioni non vengono inghiottite involontariamente. –

+0

sì è vero. ma nel mio caso il resto del codice così tanto. va bene inserire una massa di codice in una dichiarazione di prova? perché poi ogni presa in quella parte sarà catturata sotto l'una presa alla fine e per esempio non potrò a quale eccezione si riferisce a dove. – Disasterkid

1

Due opzioni vengono subito in mente:

  1. return direttamente dal all'interno di ogni catch (come suggerito BlueRaja)
  2. impostare un flag (per esempio, errorOccurred) entro i catch blocchi per le eccezioni non lo fai vuole consentire, poi mettere if (errorOccurred) return; dopo l'intero blocco try/catch

quest'ultimo potrebbe essere più rea dable ad altri sviluppatori, dal momento che è facile sfiorare ciò che accade all'interno di uno catch per capire cosa succede dopo. Vedere uno sfacciato if (errorOccurred) return; rende abbastanza difficile fraintendere quello che è successo.

1

Da una visualizzazione di alto livello, penso che questo potrebbe essere una violazione (almeno) del Principio di Responsabilità Unica se il codice sta cercando di fare qualcosa che potrebbe fallire, e poi continuare a fare altre cose.

Per il bene di una risposta, però, se si voleva fare un hack (che è sempre un male, in modo da non fare) si poteva fare

bool success = true; 
try 
{ 
    // the good ol' college try 
} 
catch (...) 
{ 
    success = false; 
} 

if (success) 
{ 
    // do the rest of your stuff 
} 

edit: o in alternativa come suggerito BlueRaja, aggiungi al codice del tuo codice nel blocco try. Se il primo bit fallisce, fallisce. Il resto del codice non funzionerà comunque.

+0

Non lo so. Tutto dipende dalla situazione e dalla logica che deve essere realizzata. Non capisco perché processare dopo farebbe male a nulla se tutto ciò che state facendo per gestire gli errori attesi è registrando e passando al prossimo codice nel metodo dopo il catch. – PositiveGuy