¿Deberíamos atrapar siempre una Excepción, envolverla y pasarla?

He leído un procedimiento de este tipo:¿Deberíamos atrapar siempre una Excepción, envolverla y pasarla?

public void doSomething throws MyException{ 
    ... 
    try { 
     doSomthingElse(); 
    } catch (MyException e){ 
     log.errer(e.getMessage()); 
     throw new MyException(e.getMessage(),e); 
    } 
    ... 
}

Pero prefiero:

public void doSomething throws MyException{ 
    ... 
    doSomthingElse();   
    ... 
}

Alguien sabe alguna razón para el primer método? Solo hay un tipo de Excepción, y no se maneja con este método, ¿hay alguna razón para atraparlo, envolverlo sin nueva información y luego pasarlo a otro? ¿Por qué no simplemente escribirlo de la segunda manera? ¡Gracias!

Fuente

2011-02-08 chance

¿Por qué todos sienten que necesitan detectar excepciones? No atrapes cosas que no puedes * hacer nada con *. Las excepciones saltan automáticamente a la pila si no las tocas. No hay absolutamente ninguna razón para * volver a tirar * ellos (y hacerlo tiene consecuencias negativas, como perder información valiosa). Y si * puedes * hacer algo con la excepción, bueno, estás bordeando sospechosamente en el territorio de usar excepciones para el control de flujo, lo que probablemente no deberías hacer en primer lugar. –

La excepción de registro y arrojarlo aún más es en realidad un antipatrón para varios reasons. La regla de oro es: si no puede hacer nada útil para manejar la excepción (el registro es no manejando la excepción en la mayoría de los casos), deje que su marco/contenedor lo haga por usted. Si puede (por ejemplo, utilizar un almacenamiento diferente cuando la base de datos no está disponible, cola de paquetes cuando la red está inactiva), registre la excepción y proceda (recuerde siempre registrar la pila también).

Si tiene una excepción marcada, envuélvala en tiempo de ejecución uno y vuelva a crear (cree su excepción personalizada o busque la existente que coincida con sus necesidades).

Fuente

2011-02-08 11:02:04

Aparte de querer registrar la excepción o hacer algo más con ella "localmente", no veo ningún motivo.

Fuente

2011-02-08 10:53:07 JHollanti

Es posible que desee capturar y registrar el error específico donde se produce, como para un mejor registro, pero luego manejarlo en un nivel superior lanzando una nueva excepción.

Fuente

2011-02-08 10:53:32 Duveit

Eso no debería ser una razón, ya que el registro se puede hacer en un nivel superior (la persona que llama del método doSomething), y desde la pila de distribución podemos deducir la ubicación de Exception. – chance

Sí, eso es cierto, pero es posible que no desee registrar todas las excepciones en un nivel superior (por alguna razón), y si es una excepción genérica, volver a convertir en una excepción específica o agregar un mensaje podría ser útil para manejarlo en una manera específica más arriba. – Duveit

El motivo de este "contenedor" en su ejemplo podría no ser alguna vez omitir una excepción y al menos iniciar sesión. No veo otro sentido en ese bloque catch, ya que generalmente se declaran para recuperarse de una excepción y tal vez hacer una "limpieza adecuada".

Prefiero heredar una clase de excepción personalizada de una excepción existente.

En el constructor de la nueva excepción, el registro se lleva a cabo. De esa forma, ahorraré la sobrecarga de generar otra Excepción nueva con rastreo completo, y la otra sobrecarga que lo acompaña.

Fuente

2011-02-08 10:55:45

Depende de la relación entre las clases. En general, prefiero delegar el registro a la persona que llama. Por lo general, la persona que llama también sabe cómo manejar una excepción: ¿volver a intentar? notificar al usuario? ¿Iniciar sesión? ¿olvidar?

Misko Hevery is a good read sobre el tema, también.

Fuente

2011-02-08 11:01:51

¿Deberíamos atrapar siempre una Excepción, envolverla y pasarla?

Respuesta

Cuestiones relacionadas