Prueba múltiple o uno?

Question

Normalmente, me gustaría hacer esto:

try 
{ 
    code 

    code that might throw an anticipated exception you want to handle 

    code 

    code that might throw an anticipated exception you want to handle 

    code 
} 
catch 
{ 

} 

¿Hay beneficios a hacerlo de esta manera?

code 

try 
{ 
    code that might throw an anticipated exception you want to handle 
} 
catch 
{ 
} 

code 

try 
{ 
    code that might throw an anticipated exception you want to handle 
} 
catch 
{ 
} 

code 

Actualización:

originalmente hice esta pregunta w/referencia a C#, pero como comentó A. Levy, se podría aplicar a cualquier idioma manejo de excepciones, así que hice las etiquetas reflejan eso.

Answer 1

Depende. Si desea proporcionar un tratamiento especial para los errores específicos a continuación, utilizar varios bloques catch:

try 
{ 
    // code that throws an exception 
    // this line won't execute 
} 
catch (StackOverflowException ex) 
{ 
    // special handling for StackOverflowException 
} 
catch (Exception ex) 
{ 
    // all others 
} 

Sin embargo, si la intención es manejar una excepción y continuar con la ejecución, colocar el código en bloques try-catch separadas:

try 
{ 
    // code that throws an exception 

} 
catch (Exception ex) 
{ 
    // handle 
} 

try 
{ 
    // this code will execute unless the previous catch block 
    // throws an exception (re-throw or new exception) 
} 
catch (Exception ex) 
{ 
    // handle 
} 

Answer 2

Segundo método es mejor en mi opinión, ya que permite atrapar errores con más precisión.
Además, envolver todo su código dentro de un gran bloque try/catch es malo, si su aplicación tiene algún tipo de problema y falla, pero como atrapó una gran aplicación genérica, la posibilidad de manejarla correctamente es menor. Debería tener partes especiales dentro de la captura de prueba, como si estuviera leyendo un archivo o respondiendo a las sugerencias del usuario. De esa manera usted puede manejar mejor que exeception

Answer 3

segundo camino, pero lo ideal es el uso de guardias de código - try/catch es costoso

Answer 4

Ni, sólo tiene que utilizar varios bloques de captura para las excepciones específicas (a menos que haya sólo una tonelada de código en el bloque y solo un par de líneas pueden arrojar una excepción. En ese caso yo iría con el segundo método).

Answer 5

Si pudiera elegir el segundo probablemente separaría esto en dos funciones.

Answer 6

Prefiero el segundo método: hace que la depuración sea más fácil, el manejo de errores es más preciso y también se alimenta muy bien en las pruebas de la unidad.

Answer 7

Segundo método. Mantener el código que podría arrojar una excepción separada de otro código - mantiene la sección más pequeña y fácil de administrar en lugar de envolver todo el código, incluso eso que no arrojará excepciones.

Answer 8

Iría por la segunda opción, pero cada vez que veo este patrón de código, mi primer sentimiento es pensar en dividirlo en múltiples funciones/métodos. Obviamente si hacerlo depende de lo que está haciendo el código;)

Answer 9

Depende de la naturaleza del tipo de errores que suceden en su código.

1. Si el manejo de esos errores que va a hacer es lo mismo ir por solo intento ... atrapar para ese grupo de código. De lo contrario, será demasiado tedioso.

2. Si los errores requieren un manejo diferente, sepárelo porque es necesario.

NO APLIQUE UN MÉTODO ÚNICO PARA TODOS LOS CASOS.LA MAYOR PARTE DE LA HORA ES CONTEXT ESPECÍFICA :)

Debe alcanzar el equilibrio entre "BUENO/COMPLEJO" y "MALO/SIMPLE". Cuanto más codifique, menos estará atrapado en este tipo de dilema :)

¡Feliz programación!

Answer 10

Estás pensando de esta manera incorrecta. ¿Qué necesitas hacer en tus bloques de captura? Si desea recuperar de cualquiera de las posibles excepciones ejecutando el mismo código, no importa qué operación arrojó la excepción, utilice un bloque catch. Si necesita hacer diferentes operaciones de limpieza dependiendo de qué operación arrojó, entonces use múltiples bloques catch.

Además, si puede usar try/finally o el patrón RAII en lugar de try/catch, entonces debería hacerlo.