Estás en lo correcto.
Se utilizan excepciones no verificadas para permitir que el sistema falle rápidamente, lo cual es bueno. Debe indicar claramente qué espera su método para que funcione correctamente. De esta manera, puede validar la entrada solo una vez.
Por ejemplo:
/**
* @params operation - The operation to execute.
* @throws IllegalArgumentException if the operation is "exit"
*/
public final void execute( String operation ) {
if( "exit".equals(operation)){
throw new IllegalArgumentException("I told you not to...");
}
this.operation = operation;
.....
}
private void secretCode(){
// we perform the operation.
// at this point the opreation was validated already.
// so we don't worry that operation is "exit"
.....
}
Solo para poner un ejemplo. El punto es que si el sistema falla rápidamente, entonces sabrás dónde y por qué falló. Obtendrás un stacktrace como:
IllegalArgumentException: I told you not to use "exit"
at some.package.AClass.execute(Aclass.java:5)
at otherPackage.Otherlass.delegateTheWork(OtherClass.java:4569)
ar ......
Y sabrás lo que pasó. OtherClass en el método "delegateTheWork" (en la línea 4569) llamó a su clase con el valor "exit", incluso cuando no debería, etc.
De lo contrario, tendría que rociar validaciones en todo el código y eso es propenso a errores. Además, a veces es difícil hacer un seguimiento de lo que salió mal y puede esperar horas de depuración frustrante
Lo mismo sucede con NullPointerExceptions. Si tiene una clase de 700 líneas con unos 15 métodos, que usa 30 atributos y ninguno de ellos puede ser nulo, en lugar de validar en cada uno de esos métodos la nulabilidad, puede hacer que todos esos atributos sean de solo lectura y validarlos en el constructor o método de fábrica
public static MyClass createInstane( Object data1, Object data2 /* etc */ ){
if( data1 == null ){ throw NullPointerException( "data1 cannot be null"); }
}
// the rest of the methods don't validate data1 anymore.
public void method1(){ // don't worry, nothing is null
....
}
public void method2(){ // don't worry, nothing is null
....
}
public void method3(){ // don't worry, nothing is null
....
}
Excepciones comprobadas Son útiles cuando el programador (usted o sus compañeros de trabajo) hicieron todo bien, validaron la entrada, realizaron pruebas y todo el código es perfecto, pero el código se conecta a un servicio web de terceros que puede estar inactivo (o un archivo que estaba usando fue eliminado por otro proceso externo, etc. El servicio web puede incluso validarse antes de intentar la conexión, pero durante la transferencia de datos algo salió mal.
En ese escenario, no hay nada que usted o sus compañeros de trabajo puedan hacer para ayudarlo. Pero aún debe hacer algo y no dejar que la aplicación simplemente muera y desaparezca a los ojos del usuario. Utiliza una excepción marcada para eso y maneja la excepción, ¿qué puede hacer cuando eso sucede ?, la mayoría de las veces, solo para intentar registrar el error, probablemente guarde su trabajo (el trabajo de la aplicación) y presente un mensaje al usuario . (El sitio blabla está inactivo, vuelva a intentarlo más tarde, etc.)
Si la excepción marcada se usa en exceso (agregando la "excepción de lanzamiento" en todas las firmas de métodos), entonces su código se volverá muy frágil, porque todos ignorarán esa excepción (porque es demasiado general) y la calidad del código será seriamente comprometidos.
Si usa en exceso la excepción no marcada, sucederá algo similar. Los usuarios de ese código no saben si algo puede salir mal y aparecerán muchos intentos {...} catch (Throwable t).