В чем преимущество объявления (Unchecked Exception) исключения по сигнатуре метода, потому что оно не заставляет вызывающую сторону сохранять блок try catch.
public void testRuntimeEx()throws RuntimeException{
if(1==1){throw new RuntimeException()}
}
//Caller method
public void testCaller(){
// not necessery to handle even caller does not known which RuntimeException might be throws then what is the benefit throws clause with method signature
testRuntimeEx();
}
Он по-прежнему служит документацией, особенно если вы используете не общее RuntimeException, а что-то более конкретное, например IllegalArgumentException или UnsupportedOperationException или IndexOutOfBoundsException, а также добавить некоторый документ JavaDoc о том, когда это произойдет.
Однако в вашем примере фрагмента кода это довольно бессмысленно.
Это объявление является сигналом для разработчика, который использует этот код, что он генерирует RuntimeException. Но пахнет не очень.
P.S. Код, который вы разместили, не будет компилироваться:
throw RuntimeException
Это не правильный бросок.
Преимущество в том, что обычно вызывающий объект не имеет ничего общего с исключением. Он ловит его, обертывает другим исключением и снова бросает. Или, наоборот, объявляет исключение с помощью ключевого слова throws и становится прозрачным для этого типа, если исключение.
Я бы сказал, что описанная ситуация типична для приложений, где мы обычно пишем бизнес-код и имеем одно централизованное место, которое обрабатывает все исключения. Это неправильно для API. Например, если вы используете библиотеку, реализующую SSH, вы ожидаете, что она выдаст IOException (или даже более специализированное исключение), когда что-то пойдет не так.
если вы выдаете пользовательское непроверенное исключение, оно становится более значимым, а не перехватывает системное исключение, а непроверенное исключение тоже не заставляет перехватывать.
