Perché catturare e riproporre un'eccezione in C #?

Sto guardando l'articolo C # - Data Transfer Object su DTO serializzabili.

L'articolo include questo pezzo di codice:

public static string SerializeDTO(DTO dto) {
    try {
        XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
        StringWriter sWriter = new StringWriter();
        xmlSer.Serialize(sWriter, dto);
        return sWriter.ToString();
    }
    catch(Exception ex) {
        throw ex;
    }
}

Il resto dell'articolo sembra sano e ragionevole (a un noob), ma quel tentativo-catch-throw genera un'eccezione Wtf ... Non è esattamente equivalente a non gestire affatto le eccezioni?

Quindi:

public static string SerializeDTO(DTO dto) {
    XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
    StringWriter sWriter = new StringWriter();
    xmlSer.Serialize(sWriter, dto);
    return sWriter.ToString();
}

O mi sto perdendo qualcosa di fondamentale sulla gestione degli errori in C #? È praticamente lo stesso di Java (meno le eccezioni controllate), non è vero? ... Cioè, hanno entrambi perfezionato C ++.

La domanda Stack Overflow La differenza tra rilanciare la cattura senza parametri e non fare nulla? sembra supportare la mia tesi secondo cui provare a catturare è un no-op.

MODIFICARE:

Riassumendo per chiunque trovi questa discussione in futuro ...

NON

try {
    // Do stuff that might throw an exception
}
catch (Exception e) {
    throw e; // This destroys the strack trace information!
}

Le informazioni sulla traccia dello stack possono essere cruciali per identificare la causa principale del problema!

FARE

try {
    // Do stuff that might throw an exception
}
catch (SqlException e) {
    // Log it
    if (e.ErrorCode != NO_ROW_ERROR) { // filter out NoDataFound.
        // Do special cleanup, like maybe closing the "dirty" database connection.
        throw; // This preserves the stack trace
    }
}
catch (IOException e) {
    // Log it
    throw;
}
catch (Exception e) {
    // Log it
    throw new DAOException("Excrement occurred", e); // wrapped & chained exceptions (just like java).
}
finally {
    // Normal clean goes here (like closing open files).
}

Cattura le eccezioni più specifiche prima di quelle meno specifiche (proprio come Java).

Riferimenti:

• MSDN - Gestione delle eccezioni
• MSDN - try-catch (Riferimenti per C #)

Primo; il modo in cui il codice dell'articolo lo fa è malvagio. throw exreimposterà lo stack di chiamate nell'eccezione al punto in cui si trova questa istruzione di lancio; perdere le informazioni su dove l'eccezione è stata effettivamente creata.

In secondo luogo, se catturi e rilasci in questo modo, non vedo alcun valore aggiunto, l'esempio di codice sopra sarebbe altrettanto buono (o, dato il throw exbit, anche migliore) senza il try-catch.

Tuttavia, ci sono casi in cui potresti voler catturare e riproporre un'eccezione. La registrazione potrebbe essere una di queste:

try 
{
    // code that may throw exceptions    
}
catch(Exception ex) 
{
    // add error logging here
    throw;
}

Non farlo

try 
{
...
}
catch(Exception ex)
{
   throw ex;
}

Perderai le informazioni sulla traccia dello stack ...

O fare

try { ... }
catch { throw; }

O

try { ... }
catch (Exception ex)
{
    throw new Exception("My Custom Error Message", ex);
}

Uno dei motivi per cui potresti voler ripensare è se stai gestendo diverse eccezioni, ad esempio

try
{
   ...
}
catch(SQLException sex)
{
   //Do Custom Logging 
   //Don't throw exception - swallow it here
}
catch(OtherException oex)
{
   //Do something else
   throw new WrappedException("Other Exception occured");
}
catch
{
   System.Diagnostics.Debug.WriteLine("Eeep! an error, not to worry, will be handled higher up the call stack");
   throw; //Chuck everything else back up the stack
}

C # (prima di C # 6) non supporta le "eccezioni filtrate" di CIL, cosa che fa VB, quindi in C # 1-5 un motivo per rilanciare un'eccezione è che non hai abbastanza informazioni al momento della cattura () per determinare se si desidera catturare effettivamente l'eccezione.

Ad esempio, in VB puoi farlo

Try
 ..
Catch Ex As MyException When Ex.ErrorCode = 123
 .. 
End Try

... che non gestirà MyExceptions con valori ErrorCode diversi. In C # prima della v6, dovresti catturare e rilanciare MyException se ErrorCode non fosse 123:

try 
{
   ...
}
catch(MyException ex)
{
    if (ex.ErrorCode != 123) throw;
    ...
}

Da C # 6.0 puoi filtrare proprio come con VB:

try 
{
  // Do stuff
} 
catch (Exception e) when (e.ErrorCode == 123456) // filter
{
  // Handle, other exceptions will be left alone and bubble up
}

Il mio motivo principale per avere un codice come:

try
{
    //Some code
}
catch (Exception e)
{
    throw;
}

è così che posso avere un punto di interruzione nel fermo, che ha un oggetto eccezione istanziato. Lo faccio molto durante lo sviluppo / debug. Naturalmente, il compilatore mi dà un avvertimento su tutte le e inutilizzate, e idealmente dovrebbero essere rimosse prima di una build di rilascio.

Sono comunque simpatici durante il debug.

Un motivo valido per riproporre le eccezioni può essere che si desidera aggiungere informazioni all'eccezione, o magari racchiudere l'eccezione originale in uno di propria creazione:

public static string SerializeDTO(DTO dto) {
  try {
      XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
      StringWriter sWriter = new StringWriter();
      xmlSer.Serialize(sWriter, dto);
      return sWriter.ToString();
  }
  catch(Exception ex) {
    string message = 
      String.Format("Something went wrong serializing DTO {0}", DTO);
    throw new MyLibraryException(message, ex);
  }
}

Non è esattamente equivalente a non gestire affatto le eccezioni?

Non esattamente, non è lo stesso. Reimposta lo stacktrace dell'eccezione. Anche se concordo sul fatto che questo probabilmente è un errore, e quindi un esempio di codice errato.

Non vuoi lanciare ex - poiché questo perderà lo stack di chiamate. Vedi Gestione delle eccezioni (MSDN).

E sì, il tentativo ... catch non sta facendo nulla di utile (a parte perdere lo stack di chiamate - quindi in realtà è peggio - a meno che per qualche motivo non volessi esporre queste informazioni).

Un punto che la gente non ha menzionato è che mentre i linguaggi .NET non fanno una vera distinzione, la questione se si debba agire quando si verifica un'eccezione e se si risolverà , in realtà sono domande distinte. Ci sono molti casi in cui si dovrebbe agire in base a eccezioni che non si hanno speranze di risolvere, e ci sono alcuni casi in cui tutto ciò che è necessario per "risolvere" un'eccezione è di svolgere lo stack fino a un certo punto - non sono necessarie ulteriori azioni .

A causa della saggezza comune secondo cui si dovrebbero solo "catturare" le cose che si possono "gestire", un sacco di codice che dovrebbe agire in caso di eccezioni, non lo fa. Ad esempio, un sacco di codice acquisirà un lucchetto, metterà l'oggetto protetto "temporaneamente" in uno stato che viola i suoi invarianti, quindi rimetterà l'oggetto in uno stato legittimo, quindi rilascerà il lucchetto prima che chiunque possa vedere l'oggetto. Se si verifica un'eccezione mentre l'oggetto si trova in uno stato pericolosamente non valido, la pratica comune è rilasciare il blocco con l'oggetto ancora in quello stato. Un modello molto migliore sarebbe quello di avere un'eccezione che si verifica mentre l'oggetto si trova in una condizione "pericolosa" invalidando espressamente il blocco, quindi qualsiasi tentativo futuro di acquisirlo fallirà immediatamente.

Nella maggior parte dei linguaggi .NET, l'unico modo per il codice di agire in base a un'eccezione è catchfarlo (anche se sa che non risolverà l'eccezione), eseguire l'azione in questione e quindi ri- throw). Un altro possibile approccio se al codice non interessa quale eccezione viene generata è l'uso di un okflag con un try/finallyblocco; imposta il okflag su falseprima del blocco e trueprima che il blocco esca e prima di qualsiasi returncosa si trovi all'interno del blocco. Quindi, all'interno finally, supponi che se oknon è impostato, deve essersi verificata un'eccezione. Tale approccio è semanticamente migliore di un catch/ throw, ma è brutto ed è meno mantenibile di quanto dovrebbe essere.

Questo può essere utile quando la tua programmazione funziona per una libreria o dll.

Questa struttura di ricodificazione può essere utilizzata per ripristinare intenzionalmente lo stack di chiamate in modo che invece di vedere l'eccezione generata da una singola funzione all'interno della funzione, si ottenga l'eccezione dalla funzione stessa.

Penso che questo sia solo usato in modo che le eccezioni generate siano più pulite e non vadano nelle "radici" della biblioteca.

Un possibile motivo per intercettare è disabilitare qualsiasi filtro delle eccezioni più approfondito dal filtraggio verso il basso ( vecchio collegamento casuale ). Ma ovviamente, se questa fosse l'intenzione, ci sarebbe un commento lì a dirlo.

Dipende da cosa stai facendo nel blocco catch e se vuoi passare l'errore al codice chiamante oppure no.

Si potrebbe dire Catch io.FileNotFoundExeption exe quindi utilizzare un percorso di file alternativo o alcuni di questi, ma ancora generare l'errore.

Anche fare Throwinvece di Throw Exconsente di mantenere la traccia dello stack completo. Throw ex riavvia la traccia dello stack dall'istruzione throw (spero che abbia senso).

Mentre molte delle altre risposte forniscono buoni esempi del motivo per cui potresti voler cogliere un'eccezione di ripensamento, nessuno sembra aver menzionato uno scenario "finalmente".

Un esempio di ciò è dove hai un metodo in cui imposti il ​​cursore (ad esempio un cursore di attesa), il metodo ha diversi punti di uscita (ad es. If () return;) e vuoi assicurarti che il cursore sia resettato fine del metodo.

Per fare ciò è possibile racchiudere tutto il codice in un tentativo / catch / infine. In infine imposta il cursore sul cursore destro. In modo da non seppellire alcuna valida eccezione, riprovare a catturare.

try
{
    Cursor.Current = Cursors.WaitCursor;
    // Test something
    if (testResult) return;
    // Do something else
}
catch
{
    throw;
}
finally
{
     Cursor.Current = Cursors.Default;
}

Nell'esempio nel codice che hai pubblicato, infatti, non ha senso catturare l'eccezione in quanto non viene fatto nulla sulla cattura che viene semplicemente riproposta, infatti fa più male che bene quando si perde lo stack di chiamate .

Tuttavia, dovresti rilevare un'eccezione per fare un po 'di logica (ad esempio chiudendo la connessione sql del blocco dei file, o solo un po' di registrazione) in caso di un'eccezione, riportandola al codice chiamante per gestire. Ciò sarebbe più comune in un livello aziendale rispetto al codice front-end, poiché è possibile che il programmatore che implementa il livello aziendale gestisca l'eccezione.

Per ripetere l'iterazione, sebbene non vi sia alcun punto nel catturare l'eccezione nell'esempio che hai pubblicato. NON farlo così!

Siamo spiacenti, ma molti esempi di "design migliorato" hanno ancora un odore orribile o possono essere estremamente fuorvianti. Avere provato {} catch {log; throw} è assolutamente inutile. La registrazione delle eccezioni deve essere eseguita in posizione centrale all'interno dell'applicazione. le eccezioni riempiono comunque lo stacktrace, perché non registrarli da qualche parte in alto e vicino ai bordi del sistema?

Si deve usare cautela quando si serializza il contesto (ad es. DTO in un dato esempio) solo nel messaggio di registro. Può facilmente contenere informazioni riservate che non si potrebbe desiderare di raggiungere le mani di tutte le persone che possono accedere ai file di registro. E se non aggiungi nuove informazioni all'eccezione, in realtà non vedo il punto del wrapping dell'eccezione. Il buon vecchio Java ha qualche punto a riguardo, richiede che il chiamante sappia che tipo di eccezioni ci si dovrebbe aspettare quindi chiamare il codice. Dal momento che non hai questo in .NET, il wrapping non fa nulla di buono su almeno l'80% dei casi che ho visto.

Oltre a ciò che hanno detto gli altri, vedi la mia risposta a una domanda correlata che mostra che catturare e ricrescere non è una no-op (è in VB, ma parte del codice potrebbe essere invocato in C # da VB).

La maggior parte delle risposte parla di scenari catch-log-rethrow.

Invece di scriverlo nel tuo codice, considera di utilizzare AOP, in particolare Postsharp.Diagnostic.Toolkit con OnExceptionOptions IncludeParameterValue e IncludeThisArgument

Riscoprire le eccezioni via throw è utile quando non si dispone di un codice specifico per gestire le eccezioni correnti o nei casi in cui si dispone di una logica per gestire casi di errore specifici ma si desidera ignorare tutti gli altri.

Esempio:

string numberText = "";
try
{
    Console.Write("Enter an integer: ");
    numberText = Console.ReadLine();
    var result = int.Parse(numberText);

    Console.WriteLine("You entered {0}", result);
}
catch (FormatException)
{
    if (numberText.ToLowerInvariant() == "nothing")
    {
        Console.WriteLine("Please, please don't be lazy and enter a valid number next time.");
    }
    else
    {
        throw;
    }
}    
finally
{
    Console.WriteLine("Freed some resources.");
}
Console.ReadKey();

Tuttavia, esiste anche un altro modo per farlo, utilizzando clausole condizionali nei blocchi catch:

string numberText = "";
try
{
    Console.Write("Enter an integer: ");
    numberText = Console.ReadLine();
    var result = int.Parse(numberText);

    Console.WriteLine("You entered {0}", result);
}
catch (FormatException) when (numberText.ToLowerInvariant() == "nothing")
{
    Console.WriteLine("Please, please don't be lazy and enter a valid number next time.");
}    
finally
{
    Console.WriteLine("Freed some resources.");
}
Console.ReadKey();

Questo meccanismo è più efficiente del rilancio di un'eccezione poiché il runtime .NET non deve ricostruire l'oggetto eccezione prima di rilanciarlo.