La differenza tra rilanciare la cattura senza parametri e non fare nulla?

Question

Supponiamo che io ho le seguenti due classi in due gruppi differenti:

//in assembly A 
public class TypeA { 
    // Constructor omitted 
    public void MethodA 
    { 
    try { 
     //do something 
    } 
    catch { 
     throw; 
    } 
    } 
} 
//in assembly B 
public class TypeB { 
    public void MethodB 
    { 
    try { 
     TypeA a = new TypeA(); 
     a.MethodA(); 
    } 
    catch (Exception e) 
     //Handle exception 
    } 
    } 
} 

In questo caso, il try-catch in MethodA solo eleva l'eccezione, ma in realtà non gestirlo. C'è qualche vantaggio nell'usare try-catch in MethodA? In altre parole, c'è una differenza tra questo tipo di blocco try-catch e non l'uso del tutto?

Answer 1

Nel tuo esempio, non vi è alcun vantaggio. Ma ci sono casi in cui è desiderabile semplicemente schiumare un'eccezione specifica.

public void Foo() 
    { 
     try 
     { 
      // Some service adapter code 

      // A call to the service 
     } 
     catch (ServiceBoundaryException) 
     { 
      throw; 
     } 
     catch (Exception ex) 
     { 
      throw new AdapterBoundaryException("some message", ex); 
     } 
    } 

Ciò consente di identificare facilmente che contorno al un'eccezione si è verificato in. In questo caso, si avrebbe bisogno per garantire la vostra eccezioni al contorno sono gettati solo per codice specifico per il contorno.

Answer 2

Con il codice nel modo in cui lo hai scritto per MethodA, non c'è differenza. Tutto ciò che farà è mangiare i cicli del processore. Tuttavia, può esserci un vantaggio nella scrittura del codice in questo modo se c'è una risorsa che è necessario liberare. Ad esempio

Resource r = GetSomeResource(); 
try { 
    // Do Something 
} catch { 
    FreeSomeResource(); 
    throw; 
} 
FreeSomeResource(); 

Tuttavia, non esiste un vero punto nel farlo in questo modo. Sarebbe molto meglio per utilizzare invece un blocco finally.

Answer 3

Il ripensamento non ha senso - è lo stesso che se non facessi nulla.

Tuttavia risulta utile quando si esegue effettivamente qualcosa: la cosa più comune è registrare l'eccezione. Puoi anche cambiare lo stato della tua classe, qualunque sia.

Answer 4

Sì, c'è una differenza. Quando si rileva un'eccezione, .NET presume che lo si gestirà in qualche modo, lo stack è svolto fino alla funzione che sta facendo il catch.

Se non lo si cattura, si verificherà un'eccezione non gestita, che invocherà una sorta di diagnostica (come un debugger o un logger di eccezioni), lo stack completo e il relativo stato nel punto di errore effettivo saranno disponibile per ispezione.

Quindi, se rilevi un'eccezione che non viene gestita altrove, rubi lo strumento diagnostico delle informazioni veramente utili su ciò che è realmente accaduto.

Answer 5

Mai fare l'opzione A. Come dice Anton, mangia la traccia dello stack. L'esempio di JaredPar mangia anche lo stacktrace. Una soluzione migliore sarebbe:

SomeType* pValue = GetValue(); 
try { 
    // Do Something 
} finally { 
    delete pValue; 
} 

Se hai qualcosa in C# che deve essere rilasciato, ad esempio, un FileStream avete ottenuto le seguenti due scelte:

FileStream stream; 
try 
{ 
    stream = new FileStream("C:\\afile.txt"); 
    // do something with the stream 
} 
finally 
{ 
    // Will always close the stream, even if there are an exception 
    stream.Close(); 
} 

O in modo più pulito:

using (FileStream stream = new FileStream("c:\\afile.txt")) 
{ 
    // do something with the stream 
} 

L'istruzione using eliminerà (e chiuderà) lo stream una volta terminato o quando viene chiusa un'eccezione.

Answer 6

Quando si riprende e si lancia, consente di impostare un punto di interruzione sulla linea throw.

Answer 7

Le eccezioni di rilancio possono essere utilizzate per incapsularlo in un'eccezione generica come ... considerare l'esempio seguente.

public class XmlException: Exception{ 
    .... 
} 

public class XmlParser{ 
    public void Parse() 
    { 
     try{ 
      .... 
     } 
     catch(IOException ex) 
     { 
     throw new XmlException("IO Error while Parsing", ex); 
     } 
    } 
} 

Ciò offre vantaggi rispetto alla categorizzazione delle eccezioni. Questo è il modo in cui i gestori di file aspx e molti altri codici di sistema eseguono l'incapsulamento delle eccezioni che determina il loro percorso verso lo stack e il loro flusso di logica.

Answer 8

Preso così com'è, la prima opzione sembrerebbe una brutta idea (o dovrebbe essere "inutile"?). Tuttavia, è raramente fatto in questo modo. Le eccezioni vengono rigettate da un blocco Catch in genere in due condizioni:

a. Si desidera controllare l'eccezione generata per i dati e condizionarla con bolle condizionali nello stack.

try 
{ 
    //do something 
} 
catch (Exception ex) 
{ 
    //Check ex for certain conditions. 
    if (ex.Message = "Something bad") 
    throw ex; 
    else 
    //Handle the exception here itself. 
} 

b. Si è verificata una condizione inaccettabile all'interno di un componente e tali informazioni devono essere comunicate al codice chiamante (in genere aggiungendo altre informazioni utili o includendole in un altro tipo di eccezione).

try 
{ 
    //do something 
} 
catch (StackOverflowException ex) 
{ 
    //Bubble up the exception to calling code 
    //by wrapping it up in a custom exception. 
    throw new MyEuphemisticException(ex, "Something not-so-good just happened!"); 
} 

Answer 9

L'assemblea A - try catch-block non ha alcun senso per me. Credo che se non gestirai l'eccezione, allora perché stai prendendo quelle eccezioni. Sarebbe comunque proiettato al livello successivo.

Tuttavia, se si sta creando un'API di livello intermedio o qualcosa del genere e la gestione di un'eccezione (e quindi di un'eccezione) in quel livello non ha senso, è possibile lanciare il proprio strato ApplicationException. Ma certamente rilanciare la stessa eccezione non ha senso.

Answer 10

Poiché le classi si trovano in 2 diversi gruppi, è possibile che si desideri o semplicemente catturare l'eccezione per registrarlo e quindi restituirlo al chiamante, in modo che possa gestirlo nel modo che ritiene opportuno. Un lancio invece di un lancio ex conserverà le informazioni contestuali su dove ha origine l'eccezione. Questo può rivelarsi utile quando l'assembly è un'API/framework in cui non devi mai ingoiare le eccezioni a meno che non sia significativo per farlo, ma comunque utile nella risoluzione dei problemi se è loggato ad esempio su EventLog.

Answer 11

È possibile utilizzare il blocco try {} catch (ex) {} nel metodo A solo se è possibile rilevare l'eccezione specifica che può essere gestita in MethodA() (ad esempio: registrazione).

Un'altra opzione è concatenare l'eccezione utilizzando la proprietà InnerException e passarla al chiamante. Questa idea non uccide la traccia dello stack.