Lanza o prueba + captura

Question

¿Cuál es la regla general a la hora de decidir si agregar una cláusula throws a un método o utilizar un try-catch?

Por lo que he leído, los lanzamientos deben usarse cuando la persona que llama ha roto su parte del contrato (objeto pasado) y el try-catch debe usarse cuando se produce una excepción durante una operación que se está realizando llevado a cabo dentro del método. ¿Es esto correcto? Si es así, ¿qué debería hacerse por el lado de las personas que llaman?

P.S: Se ha buscado a través de Google y SO, pero me gustaría tener una respuesta clara en este caso.

Answer 1

• capturar una excepción sólo si se puede manejar de una manera significativa
• declarar que lanza la excepción al alza si se va a ser manejado por el consumidor del método actual
• excepciones tiro si están causados ​​por los parámetros de entrada (pero estos son más a menudo sin control)

Answer 2

En general, un método debe lanzar una excepción a su llamador cuando no puede manejar el problema asociado localmente. P.ej. si se supone que el método debe leerse desde un archivo con la ruta especificada, IOExceptions no se puede gestionar localmente de forma sensata. Lo mismo se aplica a las entradas no válidas, agregando que mi elección personal sería lanzar una excepción sin marcar como IllegalArgumentException en este caso.

Y debe coger una excepción a un método llamado si

• es algo que puede ser manejado a nivel local (por ejemplo, tratar de convertir una cadena de entrada a un número, y si falla la conversión, es completamente válido para devolver un valor predeterminado),
• o no debe lanzarse (por ejemplo, si la excepción proviene de una capa inferior específica de la implementación, cuyos detalles de implementación no deberían ser visibles para quien llama - por ejemplo, no lo hago) Quiero mostrar que mi DAO usa Hibernate para persistir en mis entidades, por lo que capturo todas las HibernateExceptions localmente y las convierto en mis propios tipos de excepciones.

Answer 3

Mi regla de oro para personnal que es simple:

• ¿Puedo manejarlo de una manera significativa (agregado del comentario)? Así que ponga el código en try/catch. Al manejarlo, me refiero a poder informar al usuario/recuperar del error o, en un sentido más amplio, ser capaz de entender cómo esta excepción afecta la ejecución de mi código.
• Por otra parte, tirar a la basura

Nota: este replys ahora es un wiki de la comunidad, no dude en añadir más información en

Answer 4

Si el método en el que consiguió produce la excepción tiene una cantidad sufficent de la información. para enfrentarlo, debería capturar, generar información útil sobre lo que sucedió y qué datos se estaban procesando.

Answer 5

Aquí es la forma en que lo uso:

Lanza:

• Lo que desea el código para detener cuando se produce un error.
• Bueno con los métodos que son propensos a errores si se no cumplen ciertos requisitos previos.

Try-Catch:

• Cuando usted quiere tener el programa comportarse de manera diferente con diferentes errores.
• Genial si quieres proporcionar significativos errores a los usuarios finales.

Conozco a mucha gente que siempre usa Throws porque es más limpio, pero no hay tanto control.

Answer 6

La decisión de añadir un try-catch o una cláusula throws a sus métodos depende de "cómo quiere (o tiene) para manejar su excepción".

Cómo manejar una excepción es una amplia y lejos de pregunta trivial para responder. Involucra especialmente la decisión de dónde manejar la excepción y qué acciones implementar dentro del bloque catch. De hecho, cómo manejar una excepción debe ser una decisión de diseño global.

Respondiendo a sus preguntas, no hay una regla práctica.

usted tiene que decidir dónde quiere manejar su excepción y que la decisión es generalmente muy específicos a sus requisitos de dominio y de aplicación.

Answer 7

Un método debería ser solo throws una excepción si puede ofrecer garantías razonables sobre el estado del objeto, los parámetros pasados ​​al método y cualquier otro objeto sobre el que actúe el método. Por ejemplo, un método que se supone que recupera de una colección un elemento que la persona que llama espera contener en él podría ser throws una excepción marcada si el elemento que se esperaba que existiera en la colección, no lo hace. Una persona que llama que detecta esa excepción debe esperar que la colección no contenga el artículo en cuestión.

Nota que mientras Java permitirá excepciones a burbuja comprobado a través de un método que se declara como lanzar excepciones de los tipos apropiados, tal uso debe generalmente ser considerado como un anti-patrón. Imagine, por ejemplo, que algún método LookAtSky() se declara como llamando al FullMoonException, y se espera que lo arroje cuando la Luna está llena; imaginemos además, que LookAtSky() llama a ExamineJupiter(), que también se declara como throws FullMoonException. Si FullMoonException fuera lanzado por ExamineJupiter(), y si LookAtSky() no lo detecta y no lo maneja o lo envuelve en algún otro tipo de excepción, el código que llama a LookAtSky supondría que la excepción fue el resultado de que la luna de la Tierra está llena; no tendría ni idea de que una de las lunas de Júpiter podría ser la culpable.

Las excepciones que una persona que llama puede esperar manejar (incluyendo esencialmente todas las excepciones marcadas) solo deben permitirse filtrar a través de un método si la excepción significará lo mismo para la persona que llama como para el método llamado. Si el código llama a un método que se declara como arrojando alguna excepción marcada, pero la persona que llama no espera que arroje esa excepción en la práctica (por ejemplo, porque cree que es un argumento de método previamente validado), la excepción marcada debe ser capturada y ajustada en algún tipo de excepción sin marcar. Si la persona que llama no espera lanzar la excepción, la persona que llama no puede esperar que tenga un significado particular.

Answer 8

Si usa una captura de prueba, cuando se produce la excepción, los códigos restantes se seguirán ejecutando.

Si indica el método para lanzar la excepción, cuando ocurra la excepción, el código dejará de ejecutarse de inmediato.