Múltiple o simple Try Catch

Question

Estoy trabajando en la limpieza de algunos de mis códigos y llegué a un punto en el que no estaba seguro de qué ruta sería mejor.

Actualmente tengo un único bloque de captura de prueba sobre la mayoría de mi método y maneja algunas excepciones por separado al final, pero pensé que sería mejor tener más bloques de prueba para el mantenimiento. Sin embargo, mientras descifraba el código llegué a un punto en el que estaba escribiendo varios bloques para el mismo tipo de excepción. Puedo ver el lado positivo de escribir un bloque para cada parte ya que puedo dar más detalles de por qué falló.

Mi pregunta es esta ... ¿hay algún inconveniente en hacer esto? ¿Podría haber problemas de rendimiento o algún otro monstruo oculto que no estoy viendo?

Además, ¿cuál es la forma preferida de manejar múltiples excepciones en un método? ¿Existe un estándar de la industria?

Sólo para ilustrar mejor mi punto aquí es un código de pseudo

//multiple try catch for same exception 
try { 
    //some code here 
} catch (MyException e) { 
    //specific error message here 
} 
try { 
    //some different code here 
} catch (MyException e) { 
    //more specific error message indicating a different issue 
} 

Answer 1

Siempre intento para reducir los niveles de anidamiento para la legibilidad y facilidad de mantenimiento. Si n tienen los bloques try/catch, cada uno manejando el mismo tipo de excepción, por qué no refactorizar el código que puede lanzar la excepción de métodos ... que sería algo como:

try { 
    firstBatchOfTricky(); 
    secondBatchOfTricky(); 
    .... 
    nthBatchOfTricky(); 
} catch (ItWentBoomException e) { 
    // recover from boom 
} catch (ItWentBangException e) { 
    // recover from bang 
} 

Esto es mucho más fácil de leer que tener múltiples intentos/capturas. Tenga en cuenta que sus métodos deben describir lo que hacen en el espíritu del código de autoedición.

Dado que tiene su propio tipo de excepción, puede agregar los datos que necesita a la excepción para hacer cosas diferentes en el bloque catch. Cuando dice 'mensaje más específico', puede simplemente lanzar la excepción con el mensaje detallado; no deberías necesitar múltiples bloques catch. Si desea hacer cosas drásticamente diferentes en función del estado de la excepción, simplemente cree más tipos de excepción y atrape bloques, pero solo un bloque try, ya que mi pseudocódigo muestra ...

Finalmente, si no puede recuperar desde la (s) excepción (es), no debe saturar el código con bloques de captura. Lanza una excepción de tiempo de ejecución y deja que burbujee. (Un buen consejo de @tony en los comentarios)

Answer 2

Si las excepciones se pueden manejar de manera diferente (mensaje de error diferente, etc.), es correcto capturarlas por separado.

Si los tipos de excepción son diferentes, eso no significa que tenga que tener bloques try por separado, puede tener un bloque try con varias capturas.

Answer 3

Mi preferencia personal es una sola prueba que puede tener o no múltiples bloques catch. Mis métodos tienden a ser lo suficientemente pequeños donde esto tiene sentido. Si el suyo se está haciendo demasiado extenso para que sea práctico, tal vez deba pensar en refactorizar.

Una cosa sobre catch blocks: si tu catch block imprime o registra la pila y vuelve a lanzar, diría que sería mejor agregar la excepción a la cláusula throws en la firma del método y dejarla burbujear arriba.

Answer 4

Excelente pregunta. Voy a decir que deberías usar un solo bloque try-catch. Mi razonamiento: si tiene motivos para dividir su método en varios bloques try-catch, probablemente debería pensar en refactorizar su método en múltiples métodos, cada uno con su propio bloque try-catch.

Answer 5

Intento evitar repetir el código siempre que sea posible.Entonces, si la respuesta a un cierto tipo de excepción es la misma, tómalo una vez.

Answer 6

Prefiero el solo bloque try-catch. Si la longitud del método es muy grande, entonces prefiero dividir el método en múltiples métodos internos para la modularidad del alumno.
También a veces es posible que pueda volver a utilizar estos métodos internos.
Me siento de esta manera es mucho más limpio y mejor para el mantenimiento.

Answer 7

Depende de la lógica de su código - puede interrumpir su proceso (cálculo o lo que sea) en cualquier momento o puede/debe/necesita/debe controlar el flujo y revertir/notificar/verificar/atribuir si se indica alguna condición de error excepción en un paso particular.

Si está implementando un cliente RSS simple, puede mantener todos los códigos relacionados con el socket en un bloque. Pero si está escribiendo un cliente de bittorrent, necesitará una máquina de estado y un manejo de excepciones mucho más granulado.

Answer 8

Estoy de acuerdo con el consenso general de las respuestas anteriores, que un solo bloque try-catch es mejor. Sin embargo, para cuando tu método sea lo suficientemente largo como para hacerte mirar esta pregunta, es probable que sea demasiado largo. Y puede ser más fácil extraer nuevos métodos si el manejo de excepciones es más local. Aún así, creo que su mejor opción puede ser extraer métodos que simplemente arrojen la excepción y dejen el manejo de excepciones en su lugar, en el método original, idealmente en un solo bloque try-catch.

Answer 9

Esta no es una pregunta sobre desempeño o preferencias personales: es una pregunta de funcionalidad y requisitos.

Supongamos que escribo:

Escenario 1:

try 
{ 
    doThingA(); 
} 
catch (SomeException panic) 
{ 
    System.out.println("doThingA failed"); 
} 
try 
{ 
    doThingB(); 
} 
catch (SomeException panic) 
{ 
    System.out.println("doThingB failed"); 
} 

Escenario 2:

try 
{ 
    doThingA(); 
    doThingB(); 
} 
catch (SomeException panic) 
{ 
    System.out.println("doThingA or doThingB failed"); 
} 

Estos dos escenarios no son equivalentes: Ellos hacen cosas diferentes. En el Escenario 1, si doThingA arroja la excepción, doThingB todavía se ejecuta. En el Escenario 2, si doThingA arroja la excepción, doThingB no se ejecuta. Entonces, la pregunta no es cuál da un mejor rendimiento o cuál es un código más legible, sino que, si doThingA falla, ¿debería doThingB seguir ejecutándose o no?

Si lo que realmente quiere es la segunda comportamiento, pero desea diferentes mensajes para indicar al usuario lo que salió mal, entonces debe o bien lanzar excepciones diferentes, o poner el texto del mensaje en la excepción, es decir,

void doThingA() throws SomeException 
{ 
    ... whatever code ... 
    if (theWorldIsAboutToEnd) 
    throw new SomeException("doThingA failed"); 
} 

Luego, en la cláusula catch, en lugar de mostrar una cadena constante, se muestran SomeException.toString o SomeException.getMessage.

Answer 10

Parece una pregunta muy antigua. Pero mi respuesta lo relataría porque en los últimos días Java 7 ha agregado una nueva función para agregar múltiples exacepciones y el bloque catch. Esto eliminaría la gran cantidad de código y se ve muy interesante. Me encuentro con este link explianing sobre el concepto try-with-resource.

Answer 11

Es totalmente dependiente del escenario. Si hace un montón de cosas que arroja una excepción de seguridad y maneja ese escenario de la misma manera, puede usar un bloque de prueba para eso.

Sin embargo, una vez dicho esto, usar muchos bloques de prueba/captura más pequeños es a menudo mejor en mi opinión.Usar un try/catch grande es como usar varias declaraciones goto, excepto que no se puede decir de dónde vienen los gotos.

Por ejemplo, ¿cómo se puede saber qué método iría a la excepción1 y cuál iría a la excepción 2? Está bien si es un bloque pequeño, pero una vez que se hace más grande, se vuelve muy ilegible.

try{ 
    doThing1(); 
    doThing2(); 
    doThing3(); 
    doThing4(); 
    doThing5(); 
    doThing6(); 
    doThing7(); 
    doThing8(); 
    doThing9(); 
} catch (Exception1 e){ 

} catch (Exception2 e){ 

} 

A continuación está más claro.

try{ 
    doThing1();  
} catch (Exception1 e){ [...] } 
    doThing2(); 
    doThing3(); 
    doThing4(); 
    doThing5(); 
    doThing6(); 
    doThing7(); 
    doThing8(); 
try{ 
    doThing9(); 
} catch (Exception2 e){ [...] } 

Answer 12

Para estar seguro siempre utilizar bloques intento de captura individuales para cada declaración que lanza una excepción ya que si se escribe todo en un solo bloque try luego, si cualquier declaración se produce una excepción a continuación, no se ejecutan las instrucciones escritas debajo de ella.