java - example - mysql.data.mysqlclient c#

Múltiple o único Try Catch

Question

Estoy trabajando en limpiar 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 captura de prueba solo 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?

Solo para ilustrar mejor mi punto, aquí hay un pseudo código

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

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 por 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 2

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, en la parte inferior, ¿cómo puede decir 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){

}

Debajo está más claro.

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

Answer 3

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: 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 desea es el segundo comportamiento, pero desea que diferentes mensajes le digan al usuario lo que salió mal, entonces debe arrojar 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 4

Estoy de acuerdo con el consenso general de las respuestas anteriores, que un solo bloque de prueba 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 5

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 6

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 7

Mi preferencia personal es una prueba única 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 los bloques catch: si tu catch block imprime o registra el stack stack y los re-throws, diría que sería mejor que agregases la excepción a la cláusula throws en la firma del método y dejes que suba.

Answer 8

Para estar seguro siempre use bloques de captura de prueba individuales para cada instrucción de lanzamiento de excepción porque si escribe todo en un bloque de prueba, entonces si cualquier instrucción arroja una excepción, las declaraciones escritas a continuación no se ejecutarán.

Answer 9

Parece una pregunta muy vieja. 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 explicativo sobre el concepto de link .

Answer 10

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 mucho más limpio y mejor para el mantenimiento.

Answer 11

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 múltiples capturas.

Answer 12

Siempre trato de reducir los niveles de anidación para la legibilidad y el mantenimiento. Si tiene n try / catch blocks, cada uno manejando el mismo tipo de excepción, ¿por qué no refactorizar el código que puede arrojar la excepción en los métodos ... se vería algo así como:

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

Esto es mucho más legible 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.

Como 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 capture bloques, pero solo un bloque try, ya que mi pseudocódigo muestra ...

Finalmente, si no puede recuperarse de 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. (Buen consejo de @tony en los comentarios)