2010-05-18 7 views
5

Eccezione So che questo potrebbe essere un po 'strano, ma un dubbio è un dubbio dopotutto ... ciò che sarebbe accaduto nella seguente situazione ...movimentazione all'interno di una delle eccezioni in C#

private void SendMail() 
{ 
    try 
    { 
     //i try to send a mail and it throws an exception 
    } 
    catch(Exception ex) 
    { 
     //so i will handle that exception over here 
     //and since an exception occurred while sending a mail 
     //i will log an event with the eventlog 

     //All i want to know is what if an exception occurs here 
     //while writing the error log, how should i handle it?? 
    } 
} 

Grazie.

risposta

4

Vorrei ricapitolare personalmente la chiamata per scrivere nel registro eventi con un'altra istruzione try \ catch.

Tuttavia, in definitiva dipende da quali sono le vostre specifiche. Se è fondamentale per il sistema che l'errore venga scritto nel registro eventi, è necessario consentire che venga generato. Tuttavia, sulla base del tuo esempio, dubito che questo sia ciò che vuoi fare.

+6

+1. A proposito: "yo dog, ho sentito che ti piace catturare le eccezioni, quindi metto un try-catch nel tuo try-catch in modo da prenderti mentre prendi". :) – ANeves

+0

Haha Brilliant !!!!!!! Commento della settimana per quanto mi riguarda !!!! –

+0

hey David, Anche io credo che tu abbia ragione, dovremmo lasciare che la seconda eccezione venga lanciata perché alla fine se viene lanciata un'eccezione allora ciò significherebbe che il problema esiste con il computer client ... e il nostro primo preferenza è eccezioni relative alla nostra applicazione ... ma poi come faccio a sapere che errore si è verificato nella mia applicazione perché non è stata inviata una mail e non è stato registrato l'errore ??? qualsiasi suggerimento amico – Shrewdroid

0

È inoltre possibile aggiungere un blocco try-catch nel blocco catch.

1

Ogni eccezione viene catturata solo quando si trova all'interno di un blocco try-catch. Potresti annidare try-catch ma generalmente non è una buona idea.

+0

Giusto, i blocchi try-catch di nidificazione si sentono "sporchi". Tuttavia, non c'è molto altro che si possa fare. –

0

Considerando il tipo di eccezioni durante la scrittura su un file (diritti, spazio su disco ...) consiglierei di non gestirlo qui. Se fallisce la prima volta, ci sono buone probabilità che non sarai in grado di scrivere nel registro eventi che non è possibile scrivere nel registro eventi ...

Lasciare che bolla e essere gestito da un livello superiore prova a prendere.

4

È possibile rilevare gli errori nel metodo di registrazione degli errori. Tuttavia, non lo farei personalmente, poiché la registrazione errata degli errori è un segno che la tua applicazione non può funzionare affatto.

private void SendMail() 
{ 
    try 
    { 
     //i try to send a mail and it throws an exception 
    } 
    catch(Exception ex) 
    { 
     WriteToLog(); 
    } 
} 

private void WriteToLog() 
{ 
    try 
    { 
     // Write to the Log 
    } 
    catch(Exception ex) 
    { 
     // Error Will Robinson 
     // You should probably make this error catching specialized instead of pokeman error handling 
    } 
} 
+0

+1 Sì - writeToLog dovrebbe gestire le proprie eccezioni (eliminando o eliminando) –

0

Chris S. ha la migliore risposta. Posizionare un blocco try-catch all'interno di un blocco catch è molto raramente una buona idea. e nel tuo caso contorterà solo il tuo codice. Se controlli per vedere se sei riuscito a scrivere nel tuo file di registro qui, dovrai farlo in ogni posto in cui tenti di scrivere nel tuo file di registro. È possibile evitare facilmente questa duplicazione non necessaria del codice facendo sì che tutti i singoli moduli siano autonomi quando si tratta di notificare/gestire le condizioni di errore all'interno di questi moduli. Quando si invia la posta non si eseguono le azioni appropriate all'interno del vostro blocco catch per gestire questa condizione d'eccezione come:

  1. smaltimento dei contenuti del vostro oggetto di posta
  2. rendere sicuro il vostro socket viene chiuso
  3. scrittura di una voce nel file di registro per annotare l'errore

All'interno del proprio blocco catch è sufficiente chiamare qualsiasi API definita per scrivere una voce di registro nel file di registro e dimenticarsi del resto. All'interno dell'API di registrazione è possibile gestire tutti i casi eccezionali relativi alla registrazione (il disco è pieno, nessun permesso di scrittura su file, file non trovato, ecc ...). Il tuo modulo di posta non ha bisogno di sapere se la registrazione ha avuto successo o meno, che la responsabilità dovrebbe essere delegata al modulo di registrazione.

0

Gestisco personalmente questa situazione utilizzando un semplice metodo di estensione.

public static class MyExtentions 
{ 
    public static void LogToErrorFile(this Exception exception) 
    { 
     try 
     { 
      System.IO.File.AppendAllText(System.IO.Path.Combine(Application.StartupPath, "error_log.txt"), 
       String.Format("{0}\tProgram Error: {1}\n", DateTime.Now, exception.ToString())); 
     } 
     catch 
     { 
      // Handle however you wish 
     } 
    } 
} 

L'utilizzo è semplice:

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

È quindi possibile gestire l'eccezione catturato all'interno del metodo di estensione come vuoi, o semplicemente non prenderlo e lasciarlo bolla fino alla cima. Ho trovato questo design per essere un modo semplice e riproducibile per gestire le eccezioni in tutta l'applicazione.

0
  • In primo luogo, direi che non catturare "Eccezione" nel blocco catch. Si potrebbe invece, per la spedizione, verificare la validità e quindi rilevare l'eccezione specifica (SmtpException,) su cui è possibile intervenire (e informare l'utente con un messaggio amichevole). Lanciare un'eccezione dal codice e informare l'interfaccia utente non è una cattiva idea. Se i tuoi metodi accettano input con determinate specifiche e se non sono soddisfatti, il tuo metodo dovrebbe/può generare errori e informare l'utente su di esso.

  • Per le eccezioni che non hanno controllo, utilizzare l'eccezione di gestione globale, come Application_Error per web. Getting Better Information on Unhandled Exceptions Peter Bromberg spiega questo meglio.

  • Anche per qualsiasi risorsa privilegiata a cui si sta accedendo, come i registri eventi, assicurarsi che l'assembly abbia accesso ad esso.

  • Link utili Build a Really Useful ASP.NET Exception Engine By Peter A. Bromberg e Documenting Exceptional Developers By Peter A. Bromberg Per un'applicazione web guardare in Health monitoring Exception logging

  • più una cosa, se l'applicazione va storto/getta errore che non può gestire (a tutti) è meglio lasciarlo scendere con grazia e non continuare. L'applicazione in stato instabile non è una buona idea.