2011-11-11 13 views
5

Estaba viendo un código que estoy refactorizando y advierto que el código try ... catch contiene bastante código, no todos arrojarían excepciones "normales", es decir, el código no arrojaría nada o si ¿Serían excepciones totalmente fatales, como las excepciones a la memoria insuficiente?¿Está tratando de envolver el código de exceso aceptable?

Lo que me pregunto ahora es si envolver demasiado en las declaraciones try puede causar problemas con el rendimiento.

Así que ver algo como esto:

try 
{ 
    // Won't throw (I think that is the case anyway!) 
    if (e.Error == null) 
    { 
     return; 
    } 

    // Only fatal exceptions 
    myClass c = new myClass(); 

    // Now carry out the code that could cause catchable exception 
} 
catch 
{ 
} 
+0

'e.Error' * arrojará una excepción si' e' es nulo. –

+0

Comentario justo :-) Por el bien de mi pregunta, supongamos que e no es nulo. Me preguntaba si tratar de envolver aumenta el rendimiento realmente – Firedragon

+0

+1 Buena pregunta, id estar interesado en saber esto también – Purplegoldfish

Respuesta

3

Rendimiento números? Nada que debería ser notable, realmente. Desde una perspectiva de caza de insectos, sin embargo, puede ser una pesadilla. Cuando ajusta 100 líneas de código en un try/catch es más difícil averiguar cuál de esas 100 líneas arrojó una excepción. Y a pesar de toda la lógica (o en realidad debido a una lógica humana defectuosa), el código que "nunca debe lanzar una excepción" a menudo arroja más.

Digo, si tiene un código que nunca debe arrojar una excepción, haga una copia de seguridad al no envolverlo en un bloque try/catch. De lo contrario, intente/capture su método Main y termine con esto.

+0

Ese es un punto excelente en cuanto a poder seguir las excepciones si está excesivamente envuelto. Ni siquiera lo consideré por ese respeto. – Firedragon

3

A menos que una excepción es lanzada realmente un try-catch no le dará un impacto en el rendimiento medible.

Cuestiones relacionadas