Código completo en el bloque try/catch

Question

Quiero saber, ¿es good practice para colocar dentro de try block o debo colocar only the code which I feel it will cause a specific exception?
Y debería ponerse Excepción básica siempre

Código 1: código completo en el bloque try

myFunction(){ 
try{ 
    ......... 
    Code with chance of OneException 
    ............. 
}catch(OneException e){ 
    ............ 
}catch(Exception e){ 
    .............. 
} 
} 

Código 2: Sólo el código con posibilidad de excepción en el bloque try

myFunction(){ 
    ....... 
    try{ 
    Code with chance of OneException 
    }catch(OneException e){ 
    ............ 
    } 
    ............ 
} 

Código 3: Debería detectar Excepción siempre

myFunction(){ 
     ....... 
     try{ 
     Code chance of OneException 
     }catch(OneException e){ 
     ............ 
     }catch(Exception e){ 
     .............. 
     } 
     ........ 
    } 

De esto (código1, código2 y código3) ¿cuál es el mejor?
estoy conciernen principalmente con Java y C++ de codificación

Answer 1

En términos generales, debe solamente capturar las excepciones que le interesan y que se puede manejar. Es decir ... atrapa una excepción donde puedes hacer algo a la vez. el usuario no percibe el problema o cuando es explícitamente necesario informar al usuario sobre el problema.
Para todas las demás excepciones, déjeles aparecer con todos sus detalles (stacktrace, etc.) que obviamente registra. Tenga en cuenta que, obviamente, esto no significa que el usuario también deba ver esa salida de excepción sino un error genérico.

Dicho esto, supongo que cuando escribe "Code chance of OneException" sabe cómo manejar OneException, pero no Exception, ¿verdad? Entonces ... solo maneje OneException.

Answer 2

Siempre capture exactamente lo que tiene que hacer y nada más. No importa cuánto lo intentemos, no podemos hacer que nuestro código sea completamente "a prueba de idiotas". Si alguien le pasa algo que causará algún error aleatorio, entonces es su trabajo manejarlo. Si nuestro código maneja la excepción de otra persona que tiene demasiado riesgo de ser un efecto secundario inesperado.

En cuanto a lo que el código para colocar donde: código antes de la línea que podría emitir la excepción se llevará a cabo de cualquier manera, por lo que en realidad no tiene sentido tener que dentro del bloque try y antes el código que lanza . El código después de la posible excepción debe colocarse entre try y catch si y solo si depende del código de generación de excepción. Por lo tanto, si su llamada de conexión a la base de datos puede fallar, coloque todas las consultas de la base de datos dentro del bloque try.

Limitando el "tiempo" gastado en un intento ... catch hace que sea más fácil de leer y menos propenso a la captura accidental. No puedo decirte cuántas horas se han perdido porque alguien decidió atrapar una excepción que debería haberse propagado.

Answer 3

• a) Es una mala práctica, colocar código completo dentro de un bloque try.

  • a1) Además de detectar excepciones, un try-block es una documentación donde puede ocurrir una excepción. Así que colóquelo cerca de la causa, tiene en mente.
  • a2) En malas circunstancias, tiene un archivo para leer y agregar uno más para escribir, pero su excepción (FileNotFoundException) se escribió solo con el primero en mente. Un alcance reducido alrededor de los lugares problemáticos lo ayudará a identificar otros problemas.

• b) No detectar excepción básica para completar o evitar múltiples bloques de captura. Si desea escribir en un archivo, muchas cosas pueden salir mal: falta de permiso, nombre de archivo ilegal, no queda espacio en el dispositivo, .... Si le presenta al usuario un mensaje genérico ("No se pudo escribir el archivo" + nombre), no sabe qué hacer. Sea lo más específico posible, y puede informarle: "Sólo quedan 20 MB en el dispositivo" + nombre de dispositivo + "Necesitamos otros 8 MB (28 MB en total); por favor, libere espacio y repita o elija un dispositivo diferente") . Si detecta "Excepción", es probable que esté pensando en alguna excepción, pero se produce otra y no se maneja correctamente, porque el bloque de captura no se escribió teniendo en cuenta esa posibilidad. La mejor posibilidad de encontrar esta excepción es dejarla aparecer o iniciar sesión si los registros se controlan regularmente.

Se puede haber una diferencia entre el desarrollo de una aplicación, que simplemente es utilizado por los usuarios finales, o mediante el desarrollo de una API, que es utilizado por otros desarrolladores. En una API, a menudo desea incluir una excepción en una excepción propia, para que sea más fácil para los usuarios de su API manejarla, y si tiene una manera uniforme de manejar excepciones. Si su código puede lanzar muchas excepciones, y llevaría a código de cliente feo, donde su cliente tendría que especificar un montón de excepciones una y otra vez, a menudo envolver las excepciones y volver a lanzar ellos:

try { 
... 
} 
catch {FileNotFoundException fnfe} 
{ 
    throw new MyApiException (fnfe); 
} 
catch {PermissionDeniedException pde} 
{ 
    throw new MyApiException (pde); 
} 
catch {IOException ioe} 
{ 
    throw new MyApiException (ioe); 
} 

De esa manera , su cliente puede decidir cómo manejar la excepción y encontrará el tipo específico de excepción, si está interesado, dentro de su excepción.

Como Landei señala, en Java 7 habrá una técnica simplificada, para capturar múltiples excepciones, pero no sólo como una superclase común, ver this link here

Answer 4

ajustar el código en el punto donde realmente se puede manejar la excepción, y donde puedes manejar el error. Si no puede manejar el error en la función, no ajuste el código en el bloque try/catch.

No sé para Java, pero en C++ que debería tomar como referencia const:

try 
{ 
    // code that can throw an exception 
} 
catch (const SomeExceptionType & error) 
{ 
    // handle the error 
} 

Answer 5

C++ no es Java o C# o ... donde se necesita catch (o finally) cláusulas de limpiate después de ti En C++, RAII hace eso. En consecuencia, rara vez escribo try/catch declaraciones en C++, hasta el punto en que lo considero un olor a código.

Así, en lugar de contemplar el estilo de código que puedes usar en conjunción con try/catch, usted debe preguntarse si necesita que try/catch en absoluto.