Ты прав.
Непроверенные исключения используются для того, чтобы система быстро провалилась , что хорошо. Вы должны четко указать, что ожидает ваш метод, чтобы работать должным образом. Таким образом, вы можете проверить ввод только один раз.
Например:
/**
* @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"
.....
}
Просто чтобы привести пример. Дело в том, что если система быстро выходит из строя, то вы будете знать, где и почему она вышла из строя. Вы получите трассировку стека, как:
IllegalArgumentException: I told you not to use "exit"
at some.package.AClass.execute(Aclass.java:5)
at otherPackage.Otherlass.delegateTheWork(OtherClass.java:4569)
ar ......
И ты узнаешь, что случилось. OtherClass в методе "DelegateTheWork" (в строке 4569) вызвал ваш класс со значением "exit", даже если это не должно происходить и т. Д.
В противном случае вам придется разбрасывать валидации по всему коду, и это подвержено ошибкам. Кроме того, иногда трудно отследить, что пошло не так, и вы можете ожидать многочасовой отладки
То же самое происходит с исключениями NullPointerException. Если у вас есть класс на 700 строк с 15 методами, который использует 30 атрибутов, и ни один из них не может иметь значение null, вместо проверки в каждом из этих методов на обнуляемость вы можете сделать все эти атрибуты доступными только для чтения и проверить их в конструкторе или фабричный метод.
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
....
}
Проверенные исключения Полезны, когда программист (вы или ваши коллеги) все сделали правильно, проверил ввод, выполнил тесты, и весь код совершенен, но код подключается к третьей стороне Возможно, не работает веб-служба (или файл, который вы использовали, был удален другим внешним процессом и т. д.). Веб-служба может даже быть проверена перед попыткой подключения, но во время передачи данных что-то пошло не так.
В этом сценарии вы или ваши коллеги ничего не можете сделать, чтобы помочь ему. Но все же вы должны что-то сделать и не дать приложению просто умереть и исчезнуть в глазах пользователя. Для этого вы используете проверенное исключение и обрабатываете исключение. Что вы можете делать, когда это происходит? Большую часть времени вы просто пытаетесь зарегистрировать ошибку, возможно, сохранить свою работу (работу приложения) и представить сообщение пользователю. , (Сайт blabla не работает, повторите попытку позже и т. Д.)
Если проверенное исключение чрезмерно используется (добавив «throw Exception» во все сигнатуры методов), тогда ваш код станет очень хрупким, потому что все будут игнорировать это исключение (потому что оно слишком общее) и качество кода будет серьезно скомпрометирован.
Если вы злоупотребите непроверенным исключением, произойдет нечто подобное. Пользователи этого кода не знают, если что-то пойдет не так, появится много попыток {...} catch (Throwable t).