Você está certo.
Exceções não verificadas são usadas para deixar o sistema falhar rapidamente, o que é uma coisa boa. Você deve indicar claramente qual é o seu método esperado para funcionar corretamente. Dessa forma, você pode validar a entrada apenas uma vez.
Por exemplo:
/**
* @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"
.....
}
Apenas para colocar um exemplo. O ponto é que, se o sistema falhar rapidamente, você saberá onde e por que falhou. Você obterá um rastreamento de pilha 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 ......
E você saberá o que aconteceu. O OtherClass no método "delegateTheWork" (na linha 4569) chamou sua classe com o valor "exit", mesmo quando não deveria etc.
Caso contrário, você teria que espalhar as validações por todo o código e isso é propenso a erros. Além disso, às vezes é difícil rastrear o que deu errado e você pode esperar horas de depuração frustrante
O mesmo acontece com NullPointerExceptions. Se você tiver uma classe de 700 linhas com cerca de 15 métodos, que usa 30 atributos e nenhum deles pode ser nulo, em vez de validar cada um desses métodos para a nulidade, você pode tornar todos esses atributos somente leitura e validá-los no construtor ou 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
....
}
Exceções verificadas São úteis quando o programador (você ou seus colegas de trabalho) fez tudo certo, validou a entrada, executou testes e todo o código está perfeito, mas o código se conecta a um serviço da web de terceiros que pode estar inoperante (ou um arquivo você estava usando foi excluído por outro processo externo, etc). O serviço da web pode até ser validado antes da tentativa de conexão, mas durante a transferência de dados algo deu errado.
Nesse cenário, não há nada que você ou seus colegas de trabalho possam fazer para ajudá-lo. Mas você ainda precisa fazer alguma coisa e não deixar que o aplicativo morra e desapareça aos olhos do usuário. Você usa uma exceção marcada para isso e lida com a exceção, o que você pode fazer quando isso acontece ?, na maioria das vezes, apenas para tentar registrar o erro, provavelmente salve seu trabalho (o trabalho do aplicativo) e apresente uma mensagem ao usuário . (O site blabla está fora do ar, tente novamente mais tarde etc.)
Se a exceção verificada for usada em excesso (adicionando a "exceção de lançamento" em todas as assinaturas de métodos), seu código se tornará muito frágil, porque todo mundo ignorará essa exceção (porque é muito geral) e a qualidade do código será seriamente comprometida.
Se você usar a exceção desmarcada, algo semelhante acontecerá. Os usuários desse código não sabem se algo pode dar errado; muitas tentativas {...} catch (Throwable t) aparecerão.