Ten en cuenta que en la informática un problema puede tener varias soluciones, por lo tanto nosotros compartiremos la mejor y más óptimo.
Solución:
RuntimeException no están marcadas mientras que Exception están marcadas (el código de llamada debe manejarlas).
La excepción personalizada debe extenderse RuntimeException si tu quiero hacerlo sin marcar de lo contrario extiéndalo con Exception.
Con excepciones no verificadas, no se requiere que el método de código de llamada declare en su cláusula throws ninguna subclase de RuntimeException que podría lanzarse durante la ejecución del método pero no capturarse.
Como el método de llamada puede no manejar `RuntimeException“, uno debe ser cuidado al lanzar RuntimeException.
Las excepciones de tiempo de ejecución representan problemas que son el resultado de un problema de programación y, como tales, no se puede esperar razonablemente que el código del cliente API se recupere de ellas o las maneje de alguna manera. Estos problemas incluyen excepciones aritméticas, como dividir por cero; excepciones de puntero, como intentar acceder a un objeto a través de un null referencia; y la indexación de excepciones, como intentar acceder a un array elemento 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. Por lo tanto, el compilador no requiere que capture o especifique excepciones de tiempo de ejecución (aunque puede hacerlo).
Fuente/Lecturas adicionales: Excepciones no verificadas: la controversia
si te extiendes RuntimeException, no necesita declararlo en la cláusula throws (es decir, es una excepción no verificada). Si extiende Exception, lo hace (es una excepción marcada).
Algunas personas argumentan que todas las excepciones deben extenderse desde RuntimeExceptionpero si desea obligar al usuario a manejar la excepción, debe extender Exception en cambio.
Un caso en el que es una práctica común lanzar una RuntimeException es cuando el usuario llama a un método incorrectamente. Por ejemplo, un método puede verificar si uno de sus argumentos es incorrecto. null. Si un argumento es nullel método podría generar una NullPointerException, que es una excepción no verificada.
En términos generales, no lance una RuntimeException ni cree una subclase de RuntimeException simplemente porque no quiere molestarse en especificar las excepciones que pueden lanzar sus métodos.
Esta es la guía básica: si se puede esperar razonablemente que un cliente se recupere de una excepción, conviértala en una excepción marcada. Si un cliente no puede hacer nada para recuperarse de la excepción, conviértala en una excepción sin marcar.
para más leer esto.