Dando mis primeros pasos con Eclipse observo que el entorno nos ayuda al informarnos que determinados métodos pueden provocar excepciones y que estás deben ser capturadas o bien declaradas en la firma del método con la palabra clave throws (y si no le hacemos caso obtendremos los correspondientes errores de compilación). Genial.
Avanzo en mi ardua tarea y observo que no siempre se comporta de la misma manera, esto es, hay métodos que sí que pueden lanzar excepciones pero ante los cuales "no se me advierte", es decir, no estamos obligados a gestionarlas, esto es, pueden fluir a través de una pila de llamadas sin que tengan que ser ni gestionadas ni declaradas...
Investigo un poco más y me topo con el concepto de Unchecked exceptions asociado a la clase RuntimeException (y también a la clase Error, cosa "mu mala") para mí novedoso, ya que en mi periplo por .NET/C# toda excepción era unchecked por naturaleza.
Espero que el siguiente diagrama sirva de ayuda para explicarlo. Pincha aquí si realmente deseas enterarte ;-).
Aunque estoy tentado de hacerlo, no osaré en este post fijar criterio sobre a partir de qué tipo de excepción (checked vs unchecked) deberían heredar las excepciones que definamos en nuestro sistema (bueno un poco sí, aunque por ahí se dice que las Unchecked se corresponden a situaciones fruto de errores de programación... voy a "proponer" que así se clasifiquen también aquellas situaciones que no requieran una atención inmediata o próxima a su origen ;-)).
Mientras tanto, para abrir boca:
