Excepción captura de las mejores prácticas (. C#/neto)

Question

Si tengo código como este:

void a() 
{ 
    try 
    { 
     b(); 
    } 
    catch (MyException) 
    { 
     // Handle any problems that occurred in b(c(d())) 
    } 
} 

void b() 
{ 
    c(); 
    // Do something else 
} 

void c() 
{ 
    d(); 
    // Do something else 
} 

void d() 
{ 
    // Do something, throw a MyException if it fails 
} 

Suponiendo que no es necesaria la limpieza en cualquier momento, es que lo mejor es poner un try {} catch {throw;} alrededor de la llamada a d() en c() y la llamada a c() en b() o se considera correcto permitir que la excepción de d() aumente hasta a() "naturalmente" sin intervención alguna. bloques?

Supongo que el bloque adicional try/catch actúa como una especie de "documentación", pero parecen superfluas, así que me pregunto qué otras personas considerarían de la mejor manera.

Disculpe si todo esto es demasiado básico, estoy tratando de resolver excepciones, pero todavía no las siento bien.

Answer 1

Deje que se propague hasta que pueda manejarlo. Si no puedes manejarlo, no tiene sentido atraparlo. Entonces, la pregunta es, ¿se puede manejar efectivamente la excepción dentro del método c()?

Answer 2

Yo diría que depende de lo que quieras hacer con la información.

Siempre trato de detectar los problemas lo más cerca posible de la fuente: ¿por qué retroceder con el problema en lugar de tratar de resolverlo donde sucede? Para la legibilidad y la comprensión del código, también creo en try/catch tan cerca de la fuente del problema como sea posible.

Si está escribiendo el programa usted mismo, y nadie más lo tocará, haga lo que mejor funcione para usted y el código.

Answer 3

Básicamente, no. Esta no es la forma sugerida de manejar estas situaciones.

Debe detectar excepciones si y solo si puede manejarlas y hacer algo apropiado con ellas o proporcionar más información a las personas que llaman más arriba en la pila de llamadas (encapsulándola en una excepción más genérica). Si no puede hacerlo, debe dejar que la excepción salte en la pila de llamadas hasta que alguien pueda manejarla de manera apropiada.

Answer 4

La gran ventaja de las excepciones es que puede tratar los problemas donde puede hacer algo al respecto, en lugar de hacerlo directamente en la función donde, p. se detecta un archivo faltante, o en la persona que llama de la función, o su llamante, & c.

Sin embargo, las excepciones también tienen para manipular en algún punto de la cadena. El lugar donde ocurren estos puntos depende del marco que esté utilizando y en qué consiste su administración de excepciones. La pregunta clave es: ¿cuáles son sus puntos de entrada donde permitir que una excepción escape sin capturar tendría efectos negativos? Los ejemplos típicos incluyen

1. código de procesamiento de sucesos en aplicaciones de interfaz de usuario interactivos (que al menos en WinForms y ASP.NET pueden ser capturadas en masa proporcionando exception event handlers).
2. Puntos de integración donde responde mensajes externos (por ejemplo, recogiendo mensajes de una cola, procesando un archivo, escuchando en una tubería con nombre, implementando un servicio WCF).
3. Eventos de temporizador donde se procesa en segundo plano.
4. Métodos de inicio de subprocesos.

A veces, también desea detectar un error técnico general de bajo nivel y volver a considerarlo como una excepción más específica de dominio. Esto normalmente se hace en bibliotecas bien diseñadas para proteger a los usuarios de sus detalles internos de implementación. En una aplicación empresarial, es posible que desee capturar ciertas SqlExceptions y volver a lanzarlas como excepciones específicas de la aplicación (por ejemplo, YourApp.UnknownCustomer), para tratarlas a niveles superiores de lógica.

Mi consejo sería: hacer frente a los problemas al más alto nivel posible, pero asegúrese de que los captores de excepciones allí tienen excepciones razonables para trabajar. Y, por cierto, a menos que odies a tus usuarios, ¡no muestres la excepción y su rastro de pila a ellos! ;-)