Os métodos que lançam RuntimeException devem indicá-lo na assinatura do método?

Por exemplo, muitos métodos em frameworks / JDK podem lançar

java.lang.SecurityException 

mas isso não é indicado na assinatura do método (uma vez que essa é uma prática normalmente reservada para exceções verificadas). Quero argumentar que declarar RuntimeExceptions no método sigs tem muitos benefícios (semelhante à verificação de tipo estático, por exemplo). Estou bêbado ou não?

Eu não declararia uma exceção não verificada na assinatura, já que é enganosa para o usuário dessa API. Não é mais óbvio se a exceção deve ser tratada explicitamente.

Declará-lo no javadoc é uma abordagem melhor, pois permite que alguém manipule se achar necessário, mas sabendo que pode ignorá-lo se quiser. Isso torna a separação entre marcados e não marcados clara.

Do tutorial do Oracle Java :

"Se é tão bom documentar a API de um método, incluindo as exceções que ele pode lançar, por que não especificar as exceções de tempo de execução também?" As exceções de tempo de execução representam problemas resultantes de um problema de programação e, como tal, não se pode esperar que o código do cliente API se recupere deles ou os manipule de qualquer forma. Esses problemas incluem exceções aritméticas, como divisão por zero; exceções de ponteiro, como tentar acessar um objeto por meio de uma referência nula; e exceções de indexação, como a tentativa de acessar um elemento da matriz por meio de um índice muito grande ou muito pequeno.

As exceções de tempo de execução podem ocorrer em qualquer lugar em um programa e, em um programa típico, podem ser muito numerosas. Ter que adicionar exceções de tempo de execução em cada declaração de método reduziria a clareza de um programa.

Dê uma olhada no javadoc para Coleção # add

Há uma grande quantidade de exceções não verificadas mencionadas:

Throws:
UnsupportedOperationException - add is not supported by this collection.
ClassCastException - class of the specified element prevents it from being added to this collection.
NullPointerException - if the specified element is null and this collection does not support null elements.
IllegalArgumentException - some aspect of this element prevents it from being added to this collection.

Se você tiver paciência, recomendo documentar completamente as possíveis exceções lançadas por seus métodos dessa maneira. De certa forma, é ainda mais importante fazer isso para exceções não verificadas, pois as exceções verificadas são um tanto autodocumentadas (o compilador força o código de chamada a reconhecê-las).

No meu ponto de vista, é melhor declarar exceções de tempo de execução pelo menos no javadoc para o método. Declará-lo na assinatura torna ainda mais óbvio o que pode acontecer quando algo dá errado. Este é o meu principal motivo para sugerir o fornecimento desta informação.

Para sua informação: com o passar do tempo (agora em 2017), estou me inclinando muito mais a documentá-los apenas em javadoc e evitar as exceções verificadas tanto quanto possível.

Na minha opinião, as exceções não verificadas nunca devem ser declaradas na assinatura do método, pois isso é contrário à sua natureza.

Se, no entanto, é provável que um método lance algumas exceções não verificadas, observando as circunstâncias prováveis ​​em @throws em Javadoc, pode ser útil para outros que invocam o método para entender o que pode dar errado. Isso só é útil para exceções que os chamadores provavelmente serão capazes de lidar (como um NPE devido a uma entrada incorreta, etc.)

Se você estiver escrevendo uma api para ser usada por outros, há um amplo motivo para a documentação explícita de sua intenção na api e não há nenhuma desvantagem em declarar RuntimeExceptions na assinatura do método.

Isso tem a ver com a discussão sobre as exceções verificadas . A maioria concordaria que as exceções não devem ser declaradas nas assinaturas dos métodos.

Há também uma discussão sobre como as exceções de tempo de execução devem ser usadas. Concordo com um autor de que as exceções de tempo de execução devem denotar um erro de programação ou uma condição fatal. Portanto, não há muito mérito em declará-los na assinatura. Cada método poderia potencialmente através de um.