Por ejemplo, muchos métodos en frameworks / JDK pueden arrojar
java.lang.SecurityException
pero esto no se indica en la firma del método (ya que esa es una práctica normalmente reservada para las excepciones comprobadas). Quiero argumentar que declarar RuntimeExceptions en sigs de métodos tiene muchos beneficios (similar a la verificación de tipos estáticos, por ejemplo). ¿Estoy borracho o no?
Respuestas:
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 cree que es necesario, pero sabiendo que puede ignorarlo si lo desea. Esto aclara la separación entre marcado y no marcado.
Desde el tutorial de Oracle Java :
"Si es tan bueno documentar la API de un método, incluidas las excepciones que puede generar, ¿por qué no especificar también las excepciones en tiempo de ejecución?" Las excepciones en tiempo de ejecución representan problemas que son el resultado de un problema de programación y, como tal, no se puede esperar razonablemente que el código del cliente API se recupere de ellos o los maneje 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 indexació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 uno 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.
Eche un vistazo al javadoc para Collection # add
Hay una gran cantidad de excepciones no comprobadas mencionadas:
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 tiene paciencia, le recomiendo que documente a fondo las posibles excepciones arrojadas por sus métodos de esta manera. En cierto modo, es aún más importante hacer esto para las excepciones no comprobadas, ya que las excepciones comprobadas se autodocumentan (el compilador obliga al código de llamada a reconocerlas).
throwsen la firma del método. Estos no son la misma cosa. Sí, absolutamente debe documentar todas las excepciones lanzadas por su API, pero la pregunta no es sobre eso.
En mi punto de vista, es mejor declarar excepciones en tiempo de ejecución al menos en el 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 mi razón principal para sugerir que proporcione esta información.
Para su información: a medida que ha avanzado el tiempo (ahora en 2017), ahora me inclino mucho más a documentarlos solo en javadoc y evitar las excepciones marcadas tanto como sea posible.
En mi opinión, las excepciones no comprobadas nunca deben declararse en la firma del método, ya que son contrarias a su naturaleza.
Sin embargo, si es probable que un método arroje algunas excepciones no comprobadas, observar las circunstancias probables en @throws en Javadoc puede ser útil para que otros invoquen el método para comprender qué puede salir mal. Sin embargo, esto solo es útil para las excepciones que es probable que las personas que llaman puedan manejar (como una NPE debido a una entrada incorrecta, etc.)
Esto tiene que ver con la discusión sobre las excepciones marcadas . La mayoría estaría de acuerdo en que las excepciones no deben declararse en las firmas de métodos.
También hay una discusión sobre cómo se deben usar las excepciones en tiempo de ejecución. Estoy de acuerdo con un póster en que las excepciones en tiempo de ejecución deben indicar un error de programación o una condición fatal. Entonces no hay mucho mérito declararlos en la firma. Cada método podría potencialmente a través de uno.