manipulación en una excepción en C#

Question

Excepción Sé que esto podría ser un poco extraño, pero duda es duda después de todo ... lo que sucedería en la siguiente situación ...

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?? 
    } 
} 

Gracias.

Answer 1

Encerraría personalmente la llamada para escribir en el registro de eventos con otra instrucción try \ catch.

Sin embargo, en última instancia, depende de lo que especifique. Si es crítico para el sistema que la falla se escriba en el registro de eventos, entonces debe permitir que se lance. Sin embargo, basado en su ejemplo, dudo que esto sea lo que quiere hacer.

Answer 2

Puede agregar un bloque try-catch en su bloque catch también.

Answer 3

Cada excepción se detecta solo cuando se encuentra dentro de un bloque try-catch. Puedes anidar la captura de prueba, pero generalmente no es una buena idea.

Answer 4

Teniendo en cuenta el tipo de excepciones al escribir en un archivo (derechos, espacio en disco ...), me gustaría no manejarlo aquí. Si falla la primera vez, hay buenas posibilidades de que no pueda escribir en el registro de eventos que no es posible escribir en el registro de eventos ...

Deje que burbujee y sea manejado por un nivel superior trata de atraparlo.

Answer 5

Simplemente puede detectar errores en el método de registro de errores. Sin embargo, yo personalmente no lo haría, ya que el registro de errores interrumpido es una señal de que su aplicación no puede funcionar en absoluto.

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 
    } 
} 

Answer 6

Chris S. tiene la mejor respuesta. Colocar un bloque try-catch dentro de un bloque catch es muy rara vez una buena idea. y en su caso, solo convolucionará su código. Si comprueba si tuvo éxito escribiendo su archivo de registro aquí, tendrá que hacerlo en todos los lugares donde intente escribir en su archivo de registro. Puede evitar fácilmente esta duplicación de código innecesaria haciendo que todos sus módulos individuales sean independientes cuando se trata de notificar/manejar las condiciones de error dentro de estos módulos. Cuando se envía el correo no llevar a cabo las acciones adecuadas dentro de su bloque catch para controlar esta condición excepcional como:

1. desechar el contenido de su correo electrónico objeto
2. asegurándose de que su socket está cerrado
3. escribir una entrada en su archivo de registro para observar el error

Dentro de su bloque catch simplemente llame a cualquier API que haya definido para escribir una entrada de registro en su archivo de registro y olvidarse del resto. Dentro de su API de registro es donde debe manejar cualquier caso excepcional relacionado con el registro (el disco está lleno, no tiene permiso para escribir en el archivo, no se encuentra el archivo, etc.). Su módulo de correo no necesita saber si el registro fue exitoso o no, esa responsabilidad debería ser delegada al módulo de registro.

Answer 7

Personalmente manejo esta situación usando un método de extensión simple.

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 
     } 
    } 
} 

El uso es simple:

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

A continuación, puede controlar la excepción atrapado en el interior del método de extensión que le apetezca, o simplemente no coger y dejar que suben a la parte superior. Descubrí que este diseño es una forma simple y reproducible de manejar excepciones en toda la aplicación.

Answer 8

• En primer lugar, diría que no captures "Exception" en catch block. En su lugar, podría enviar correos electrónicos para verificar la validez y luego detectar excepciones específicas (SmtpException) sobre las que puede hacer algo (e informar al usuario con un mensaje amigable). Lanzar una excepción de su código e informar a la UI sobre esto no es una mala idea. Si sus métodos aceptan entradas con ciertas especificaciones y si no se cumplen, su método debe/puede arrojar un error e informar al usuario al respecto.

• Para las excepciones que no tienen control, use excepción de manejo global, como Application_Error para web. Getting Better Information on Unhandled Exceptions Peter Bromberg lo explica mejor.

• También para cualquier recurso privado al que esté accediendo, como eventlogs, asegúrese de que el ensamblado tenga acceso a él.

• Enlaces útiles Build a Really Useful ASP.NET Exception Engine By Peter A. Bromberg y Documenting Exceptional Developers By Peter A. Bromberg Para la aplicación web se vean en Health monitoring Exception logging

• Una cosa más, si su aplicación va mal/lanza de error que no puede manejar (en absoluto) es mejor para dejarlo ir con gracia y no continuar. La aplicación en estado inestable no es buena idea.