¿Deberían los métodos que lanzan RuntimeException indicarlo en la firma del método?

Question

Por ejemplo, muchos métodos en los marcos/JDK pueden tirar

java.lang.SecurityException 

pero esto no está indicado en la firma del método (ya que es una práctica normalmente reservado para excepciones controladas). Quiero argumentar que la declaración de RuntimeExceptions en el método sigs tiene muchos beneficios (similar a la comprobación de tipo estático, por ejemplo). ¿Estoy borracho o no?

Answer 1

No declararía una excepción sin marcar en la firma, ya que es engañosa para el usuario de esa API. Ya no es obvio si la excepción debe manejarse explícitamente.

Declararlo en el javadoc es un mejor enfoque, ya que le permite a alguien manejarlo si lo considera necesario, pero sabiendo que puede ignorarlo si lo desea. Esto hace que la separación entre claro y sin marcar sea claro.

Answer 2

En mi opinión, es mejor declarar las excepciones de tiempo de ejecución al menos en javadoc para el método. Declararlo en la firma hace que sea aún más obvio lo que puede suceder cuando algo sale mal. Esta es la razón principal por la que sugiero proporcionar esta información.

FYI: como el tiempo ha progresado (ahora en 2017) ahora me inclino mucho más a documentarlos en javadoc y evitar las excepciones comprobadas tanto como sea posible.

Answer 3

Esto tiene que ver con la discusión sobre checked exceptions. La mayoría estaría de acuerdo en que las excepciones no deberían declararse en las firmas de métodos.

También hay un discussion con respecto a cómo se deben usar las excepciones de tiempo de ejecución. Estoy de acuerdo con un cartel en que las excepciones de tiempo de ejecución deben denotar un error de programación o una condición fatal. Entonces no hay mucho mérito al declararlos en la firma. Cada método podría potencialmente a través de uno.

Answer 4

En mi opinión, las excepciones sin marcar nunca se deben declarar en la firma del método, ya que eso es contrario a su naturaleza.

Si, sin embargo, es probable que un método arroje algunas excepciones sin marcar, las circunstancias probables en @throws en Javadoc pueden ser útiles para otros que invocan el método para comprender qué puede salir mal. Esto sólo es útil, aunque para excepciones que las personas que llaman es probable que sea capaz de manejar (como un NPE debido al mal de entrada, etc.)

Answer 5

Tome una mirada en el Javadoc para Collection # añaden

Hay un todo serie de excepciones sin marcar, mencionó:

Throws: 
UnsupportedOperationException - add is not supported by this collection. 
ClassCastException - class of the specified element prevents it from being added to this collection. 
NullPointerException - if the specified element is null and this collection does not support null elements. 
IllegalArgumentException - some aspect of this element prevents it from being added to this collection. 

Si usted tiene la paciencia, me gustaría recomendar documentar minuciosamente las posibles excepciones lanzadas por sus métodos de esta manera. En cierto modo, es aún más importante hacer esto para las excepciones no verificadas, ya que las excepciones comprobadas son de alguna manera autodocumentadas (el compilador obliga al código de llamada a reconocerlas).

Answer 6

Si está escribiendo una API para su uso por parte de terceros, existe un amplio motivo para la documentación explícita de su intención en la API y no hay inconvenientes para declarar RuntimeExceptions en la firma del método.

Answer 7

De the Oracle Java tutorial:

"Si es tan buena para documentar la API de un método, incluidas las excepciones puede lanzar, por qué no especificar excepciones de tiempo de ejecución también?" Las excepciones en tiempo de ejecución representan problemas que son el resultado de un problema de programación , y, como tal, el código del cliente API no puede razonablemente ser espera recuperarse de ellos o manejarlos de ninguna manera. Tales problemas incluyen excepciones aritméticas, como dividir por cero; excepciones de puntero, como intentar acceder a un objeto a través de una referencia nula; y excepciones de indización, como intentar acceder a un elemento de matriz a través de un índice que es demasiado grande o demasiado pequeño.

Las excepciones de tiempo de ejecución pueden ocurrir en cualquier parte de un programa, y ​​en un típico pueden ser muy numerosas. Tener que agregar excepciones de tiempo de ejecución en cada declaración de método reduciría la claridad de un programa.