SÍ. De acuerdo con Effective Java -
Mientras que la especificación del lenguaje Java no lo requiere, hay una fuerte convención de que los errores están reservados para su uso por la JVM para indicar las deficiencias de recursos, fallas invariantes, u otras condiciones que hacen imposible continuar la ejecución. Dada la aceptación casi universal de esta convención, es mejor no implementar ninguna subclase de error nueva. Por lo tanto, todos los throwables no revisados que implemente deben subclasificar RuntimeException (directa o indirectamente).
A continuación el uso de excepción no comprobada se recomienda: -
- Utilice excepciones de tiempo de ejecución para indicar los errores de programación.
- Si cree que una condición puede permitir la recuperación, use una excepción marcada; si no, use una excepción de tiempo de ejecución. Si no está claro si la recuperación es posible, probablemente sea mejor que utilice una excepción sin marcar.
Acerca de la documentación sin control excepción -
utilice la etiqueta el Javadoc @throws para documentar cada una excepción no comprobada de que un método puede lanzar, pero no utilice los tiros de palabras clave para incluir sin marcar excepciones en el método declaración.
Solo tenga en cuenta que agregar nuevas excepciones al código existente básicamente rompe la compatibilidad con las versiones anteriores de su API. Claro, si solo agregas RuntimeExceptions, sigue siendo compatible con binarios, pero personalmente considero que es aún peor: las personas que no sepan ahora se vincularán a la nueva versión y de repente obtendrán errores extraños. Ugh. – Voo