Когда выбирать проверенные и непроверенные исключения

https://stackoverflow.com/questions/27578

09-06-2019
|

Вопрос

В Java (или любом другом языке с проверяемыми исключениями), при создании вашего собственного класса исключений, как вы решаете, должен ли он быть отмечен или снят?

Мой инстинкт подсказывает, что проверяемое исключение будет вызываться в случаях, когда вызывающий может быть в состоянии восстановиться каким-либо продуктивным способом, тогда как непроверенное исключение было бы больше для неустранимых случаев, но мне было бы интересно узнать мысли других.

Решение

Проверенные исключения хороши, если вы понимаете, когда их следует использовать.Java core API не выполняет эти правила для SQLException (а иногда и для IOException), вот почему они такие ужасные.

Проверенные исключения следует использовать для предсказуемый, но необратимый ошибки, которые являются разумно оправиться от.

Непроверенные исключения должен использоваться для всего остального.

Я объясню это для вас, потому что большинство людей неправильно понимают, что это значит.

Предсказуемый, но непредсказуемый:Вызывающий объект сделал все, что было в его силах, для проверки входных параметров, но какое-то независящее от него условие привело к сбою операции.Например, вы пытаетесь прочитать файл, но кто-то удаляет его в промежуток времени между проверкой, существует ли он, и началом операции чтения.Объявляя проверяемое исключение, вы сообщаете вызывающей стороне, чтобы она предвидела этот сбой.
Разумно оправиться от:Нет смысла говорить вызывающим абонентам предвидеть исключения, после которых они не смогут восстановиться.Если пользователь пытается выполнить чтение из несуществующего файла, вызывающий может запросить у него новое имя файла.С другой стороны, если метод завершается с ошибкой из-за ошибки программирования (недопустимые аргументы метода или некорректная реализация метода), приложение ничего не может сделать, чтобы устранить проблему в середине выполнения.Лучшее, что он может сделать, - это зарегистрировать проблему и ждать, пока разработчик исправит ее позже.

Если только исключение, которое вы создаете, не соответствует ВСЕ из вышеперечисленных условий он должен использовать Непроверенное исключение.

Проводите переоценку на всех уровнях:Иногда метод, перехватывающий проверенное исключение, не является подходящим местом для обработки ошибки.В таком случае подумайте, что разумно для ваших собственных абонентов.Если исключение предсказуемо, непредотвратимо и разумно для восстановления, то вам следует создать проверенное исключение самостоятельно.Если нет, вам следует обернуть исключение в непроверенное исключение.Если вы будете следовать этому правилу, то обнаружите, что преобразуете проверенные исключения в непроверенные и наоборот, в зависимости от того, на каком уровне вы находитесь.

Как для проверенных, так и для непроверенных исключений, используйте правильный уровень абстракции.Например, репозиторий кода с двумя разными реализациями (база данных и файловая система) должен избегать раскрытия специфичных для реализации деталей путем добавления SQLException или IOException.Вместо этого он должен обернуть исключение в абстракцию, которая охватывает все реализации (например RepositoryException).

Другие советы

От Изучающий Java:

Когда возникает исключение, вы должны либо перехватить и обработать исключение, либо сообщить компилятору, что вы не можете обработать это, объявив, что ваш метод выдает это исключение, тогда код , использующий ваш метод, должен будет обработайте это исключение (даже если оно также может объявить, что оно выдает исключение, если он не может с этим справиться).

Компилятор проверит, что мы выполнили одну из двух вещей (catch или declare).Таким образом, они называются проверяемыми исключениями.Но ошибки и исключения во время выполнения не проверяются компилятором (хотя вы можете выбрать перехватывать или объявлять, это не обязательно).Итак, эти два называются Непроверенные исключения.

Ошибки используются для обозначения тех условий, которые возникают вне приложения, таких как сбой системы.Исключения во время выполнения обычно возникают по ошибке в логике приложения .Ты ничего не можешь сделать в таких ситуациях.При возникновении исключения во время выполнения вам необходимо переписать программный код заново.Таким образом, они не проверяются компилятором.Эти исключения во время выполнения будут выявлены в ходе периода разработки и тестирования.Затем мы должны провести рефакторинг нашего кода, чтобы удалить эти ошибки.

Правило, которое я использую, таково:никогда не используйте непроверенные исключения!(или когда вы не видите никакого способа обойти это)

Есть очень веские доводы в пользу обратного:Никогда не используйте проверяемые исключения.Я неохотно принимаю чью-либо сторону в дебатах, но, похоже, существует широкий консенсус в отношении того, что введение проверяемых исключений было неправильным решением, оглядываясь назад.Пожалуйста, не стреляйте в курьера и обратитесь к эти аргументы.

В любой достаточно большой системе со многими уровнями проверяемое исключение бесполезно, так как в любом случае вам нужна стратегия архитектурного уровня для обработки того, как будет обрабатываться исключение (используйте барьер ошибок).

С проверенными исключениями ваша статистика обработки ошибок управляется на микроуровне, и это невыносимо в любой большой системе.

В большинстве случаев вы не знаете, является ли ошибка "восстанавливаемой", потому что вы не знаете, на каком уровне находится вызывающий ваш API.

Допустим, я создаю API stringtointкоторый преобразует строковое представление целого числа в Int.Должен ли я выдавать проверяемое исключение, если API вызывается со строкой "foo" ?Можно ли это восстановить ?Я не знаю, потому что на своем уровне вызывающий мой STRINGTOINTAPI, возможно, уже проверил входные данные, и если это исключение сгенерировано, это либо ошибка, либо повреждение данных, и оно не подлежит восстановлению для этого уровня.

В этом случае вызывающий API не хочет перехватывать исключение.Он только хочет, чтобы исключение "всплывало".Если я выберу проверяемое исключение, у этого вызывающего будет много бесполезного блока catch только для искусственного повторного создания исключения.

То, что можно восстановить, в большинстве случаев зависит от вызывающего API, а не от автора API.API не должен использовать проверенные исключения, поскольку только непроверенные исключения позволяют либо перехватывать, либо игнорировать исключение.

Вы правы.

Непроверенные исключения используются для того, чтобы система быстро терпит неудачу и это хорошо.Вы должны четко указать, чего ожидает ваш метод, чтобы работать должным образом.Таким образом, вы можете проверить входные данные только один раз.

Например:

/**
 * @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"
      .....  
 }

Просто для того, чтобы привести пример.Дело в том, что если система быстро выйдет из строя, то вы будете знать, где и почему она вышла из строя.Вы получите stacktrace, подобный:

 IllegalArgumentException: I told you not to use "exit" 
 at some.package.AClass.execute(Aclass.java:5)
 at otherPackage.Otherlass.delegateTheWork(OtherClass.java:4569)
 ar ......

И ты узнаешь, что произошло.Другой класс в методе "delegateTheWork" (в строке 4569) вызвал ваш класс со значением "exit", даже если этого не должно быть и т.д.

В противном случае вам пришлось бы разбрасывать проверки по всему вашему коду, а это чревато ошибками.Кроме того, иногда бывает трудно отследить, что пошло не так, и вас могут ожидать часы утомительной отладки

То же самое происходит с NullPointerExceptions.Если у вас есть класс из 700 строк с примерно 15 методами, который использует 30 атрибутов, и ни один из них не может быть нулевым, вместо проверки в каждом из этих методов на обнуляемость вы могли бы сделать все эти атрибуты доступными только для чтения и проверять их в конструкторе или фабричном методе.

 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" в сигнатуры всех методов ), то ваш код станет очень хрупким, потому что все будут игнорировать это исключение ( потому что оно слишком общее ), и качество кода будет серьезно подорвано.

Если вы злоупотребляете непроверенным исключением, произойдет нечто подобное.Пользователи этого кода не знают, может ли что-то пойти не так, и появится множество try{...}catch( Throwable t).

Вот мое "последнее эмпирическое правило".
Я использую:

непроверенное исключение в коде моего метода для сбой из-за вызывающего абонента (это включает в себя четкая и полная документация)
проверенное исключение для сбой из-за вызываемый абонент это мне нужно четко разъяснить всем, кто хочет использовать мой код

По сравнению с предыдущим ответом, это четкое обоснование (с которым можно согласиться или не согласиться) использования того или иного (или обоих) видов исключений.

Для обоих этих исключений я создам свое собственное непроверенное исключение для моего приложения (хорошая практика, как уже упоминалось здесь), за исключением очень распространенного непроверенного исключения (например, NullPointerException)

Так, например, цель этой конкретной функции ниже - создать (или получить, если она уже существует) объект,
значение:

контейнер объекта для создания / получения ДОЛЖЕН существовать (ответственность ВЫЗЫВАЮЩЕГО объекта
=> непроверенное исключение И очистить комментарий javadoc для этой вызываемой функции)
остальные параметры не могут быть равны нулю
(выбор программиста, который передаст это ВЫЗЫВАЮЩЕМУ АБОНЕНТУ:программист не будет проверять наличие параметра null, но ОН ЕГО ДОКУМЕНТИРУЕТ)
результат НЕ МОЖЕТ БЫТЬ НУЛЕВЫМ
(ответственность и выбор кода вызываемого абонента, выбор которого будет представлять большой интерес для вызывающего абонента
=> проверенное исключение, потому что каждый вызывающий ДОЛЖЕН принять решение, если объект не может быть создан / найден, и это решение должно быть приведено в исполнение во время компиляции:они не могут использовать эту функцию без необходимости иметь дело с этой возможностью, то есть с этим проверено исключение).

Пример:

/**
 * Build a folder. <br />
 * Folder located under a Parent Folder (either RootFolder or an existing Folder)
 * @param aFolderName name of folder
 * @param aPVob project vob containing folder (MUST NOT BE NULL)
 * @param aParent parent folder containing folder 
 *        (MUST NOT BE NULL, MUST BE IN THE SAME PVOB than aPvob)
 * @param aComment comment for folder (MUST NOT BE NULL)
 * @return a new folder or an existing one
 * @throws CCException if any problems occurs during folder creation
 * @throws AssertionFailedException if aParent is not in the same PVob
 * @throws NullPointerException if aPVob or aParent or aComment is null
 */
static public Folder makeOrGetFolder(final String aFoldername, final Folder aParent,
    final IPVob aPVob, final Comment aComment) throws CCException {
    Folder aFolderRes = null;
    if (aPVob.equals(aParent.getPVob() == false) { 
       // UNCHECKED EXCEPTION because the caller failed to live up
       // to the documented entry criteria for this function
       Assert.isLegal(false, "parent Folder must be in the same PVob than " + aPVob); }

    final String ctcmd = "mkfolder " + aComment.getCommentOption() + 
        " -in " + getPNameFromRepoObject(aParent) + " " + aPVob.getFullName(aFolderName);

    final Status st = getCleartool().executeCmd(ctcmd);

    if (st.status || StringUtils.strictContains(st.message,"already exists.")) {
        aFolderRes = Folder.getFolder(aFolderName, aPVob);
    }
    else {
        // CHECKED EXCEPTION because the callee failed to respect his contract
        throw new CCException.Error("Unable to make/get folder '" + aFolderName + "'");
    }
    return aFolderRes;
}

Дело не только в способности восстановиться после исключения.Что, на мой взгляд, важнее всего, так это то, заинтересован ли вызывающий в перехвате исключения или нет.

Если вы пишете библиотеку для использования в другом месте или на более низком уровне в вашем приложении, спросите себя, заинтересован ли вызывающий объект в том, чтобы перехватить (узнать о) ваше исключение.Если это не так, то используйте непроверенное исключение, чтобы не обременять его понапрасну.

Это философия, используемая многими фреймворками.В частности, на ум приходят Spring и hibernate - они преобразуют известное проверяемое исключение в непроверенное именно потому, что проверяемые исключения чрезмерно используются в Java.Один пример, который я могу привести, - это исключение JSONException из json.org, которое является проверяемым исключением и в основном раздражает - оно должно быть снято, но разработчик просто не продумал это до конца.

Кстати, в большинстве случаев интерес вызывающего абонента к исключению напрямую связан с возможностью восстановления после исключения, но это не всегда так.

Вот очень простое решение вашей дилеммы "Проверено / Непроверено".

Правило 1:Думайте о Непроверенном исключении как о тестируемом условии перед выполнением кода.например…

x.doSomething(); // the code throws a NullPointerException

где x равно нулю...... возможно, код должен содержать следующее…

if (x==null)
{
    //do something below to make sure when x.doSomething() is executed, it won’t throw a NullPointerException.
    x = new X();
}
x.doSomething();

Правило 2:Думайте о проверяемом исключении как о непроверяемом условии, которое может возникнуть во время выполнения кода.

Socket s = new Socket(“google.com”, 80);
InputStream in = s.getInputStream();
OutputStream out = s.getOutputStream();

... в приведенном выше примере URL (google.com) может быть недоступен из-за того, что DNS-сервер не работает.Даже в тот момент, когда DNS-сервер работал и решил ‘google.com’ имя в IP-адрес, если подключение производится к google.com В любое время послесловие, сеть может пойти вниз.Вы просто не можете постоянно тестировать сеть перед чтением и записью в потоки.

Бывают случаи, когда код просто должен выполняться, прежде чем мы сможем узнать, есть ли проблема.Заставляя разработчиков писать свой код таким образом, чтобы заставить их справляться с подобными ситуациями с помощью проверяемого исключения, я должен снять шляпу перед создателем Java, который изобрел эту концепцию.

В общем, почти все API в Java следуют двум приведенным выше правилам.Если вы попытаетесь выполнить запись в файл, диск может заполниться до завершения записи.Вполне возможно, что другие процессы привели к переполнению диска.Просто нет способа проверить эту ситуацию.Для тех, кто взаимодействует с оборудованием, где в любой момент использование оборудования может привести к сбою, проверенные исключения кажутся элегантным решением этой проблемы.

В этом есть серая область.В случае, если требуется много тестов (умопомрачительный оператор if с большим количеством && и ||), генерируемым исключением будет CheckedException просто потому, что его слишком сложно выполнить правильно — вы просто не можете сказать, что эта проблема является ошибкой программирования.Если имеется гораздо меньше 10 тестов (например,‘if (x == null)’), тогда ошибка программиста должна быть UncheckedException.

Когда имеешь дело с языковыми переводчиками, все становится интереснее.Согласно приведенным выше правилам, должна ли Синтаксическая ошибка рассматриваться как Проверенное или Непроверенное исключение?Я бы сказал, что если синтаксис языка может быть протестирован до его выполнения, это должно быть исключение UncheckedException.Если язык не может быть протестирован — аналогично тому, как ассемблерный код выполняется на персональном компьютере, то синтаксическая ошибка должна быть Проверяемым исключением.

Приведенные выше 2 правила, вероятно, устранят 90% ваших опасений по поводу того, из чего выбирать.Чтобы суммировать правила, следуйте этому шаблону… 1) если код, подлежащий выполнению, может быть протестирован перед его выполнением на корректность и если возникает исключение — также известное как.ошибка программиста, исключением должно быть исключение UncheckedException (подкласс RuntimeException).2) если код, который должен быть выполнен, не может быть протестирован перед его выполнением для корректной работы, исключение должно быть проверяемым исключением (подкласс Exception).

Вы можете назвать это проверенным или непроверенным исключением;однако, и то , и другое типы исключений могут быть перехвачены программистом, поэтому лучшим ответом будет:писать ВСЕ из ваших исключений как непроверенный и документируйте их.Таким образом, разработчик, использующий ваш API, может выбрать, хочет ли он или она перехватить это исключение и что-то сделать.Проверяемые исключения - это пустая трата времени каждого, и это превращает ваш код в шокирующий кошмар на вид.Правильное модульное тестирование затем выявит любые исключения, которые вам, возможно, придется перехватить и с чем-то сделать.

Проверенное исключение: Если клиент может восстановиться после исключения и хотел бы продолжить, используйте проверенное исключение.

Непроверенное исключение: Если клиент не может ничего сделать после исключения, то вызовите непроверенное исключение.

Пример:Если ожидается, что вы будете выполнять арифметические операции в методе A() и на основе выходных данных A(), вам придется выполнить другую операцию.Если выходные данные метода A() равны нулю, чего вы не ожидаете во время выполнения, то ожидается, что вы выдадите исключение нулевого указателя, которое является исключением во время выполнения.

Ссылаться здесь

Я согласен с предпочтением непроверенных исключений, как правило, особенно при разработке API.Вызывающий объект всегда может перехватить документированное, непроверенное исключение.Вы просто не заставляете абонента к этому без необходимости.

Я нахожу проверенные исключения полезными на более низком уровне, в качестве деталей реализации.Часто кажется, что это лучший механизм управления потоком, чем необходимость управлять указанной ошибкой "код возврата".Иногда это может помочь увидеть влияние идеи и на изменение низкоуровневого кода...объявите проверяемое исключение ниже по потоку и посмотрите, кому потребуется внести коррективы.Этот последний пункт неприменим, если существует много общих: catch(Исключение e) или вызывает Исключение что в любом случае обычно не слишком хорошо продумано.

Вот я и хочу поделиться своим мнением, которое сложилось у меня после многолетнего опыта разработки:

Проверенное исключение.Это часть бизнес-сценария использования или потока вызовов, это часть логики приложения, которую мы ожидаем или не ожидаем.Например, соединение отклонено, условие не выполнено и т.д.Нам нужно обработать это и показать соответствующее сообщение пользователю с инструкциями, что произошло и что делать дальше (повторите попытку позже и т.д.).Обычно я называю это исключением после обработки или "пользовательским" исключением.
Непроверенное исключение.Это является частью исключения при программировании, некоторой ошибкой в программировании программного кода (баг, дефект) и отражает способ, которым программисты должны использовать API в соответствии с документацией.Если во внешнем документе lib / framework указано, что он ожидает получить данные в некотором диапазоне, отличном от null, потому что будет выдано исключение NPE или IllegalArgumentException, программист должен ожидать этого и правильно использовать API в соответствии с документацией.В противном случае будет выдано исключение.Обычно я называю это исключением предварительной обработки или исключением "проверки".

По целевой аудитории.Теперь давайте поговорим о целевой аудитории или группе людей, для которых были разработаны исключения (по моему мнению).:

Проверенное исключение.Целевая аудитория - пользователи/клиенты.
Непроверенное исключение.Целевая аудитория - разработчики.Другими словами, непроверенные исключения предназначены только для разработчиков.

По этапам жизненного цикла разработки приложений.

Проверяемое исключение предназначено для существования в течение всего жизненного цикла продукта в качестве обычного и ожидаемого механизма, с помощью которого приложение обрабатывает исключительные случаи.
Непроверенное исключение предназначено для существования только в течение жизненного цикла разработки / тестирования приложения, все они должны быть исправлены в течение этого времени и не должны выдаваться, когда приложение уже запущено в рабочей среде.

Причина, по которой фреймворки обычно используют непроверенные исключения (например, Spring), заключается в том, что фреймворк не может определить бизнес-логику вашего приложения, это зависит от разработчиков, которые должны перехватить их и разработать собственную логику.

Отмеченные исключения полезны для восстанавливаемых случаев, когда вы хотите предоставить информацию вызывающему абоненту (т. е.недостаточные разрешения, файл не найден и т.д.).

Непроверенные исключения используются редко, если используются вообще, для информирования пользователя или программиста о серьезных ошибках или непредвиденных условиях во время выполнения.Не создавайте их, если вы пишете код или библиотеки, которые будут использоваться другими пользователями, поскольку они могут не ожидать, что ваше программное обеспечение будет выдавать непроверенные исключения, поскольку компилятор не заставляет их перехватываться или объявляться.

Всякий раз, когда исключение с меньшей вероятностью ожидается, и мы можем продолжить работу даже после его обнаружения, и мы ничего не можем сделать, чтобы избежать этого исключения, тогда мы можем использовать проверенное исключение.

Всякий раз, когда мы хотим сделать что-то значимое, когда происходит определенное исключение и когда это исключение ожидается, но не наверняка, мы можем использовать проверенное исключение.

Всякий раз, когда исключение перемещается по разным слоям, нам не нужно перехватывать его в каждом слое, в этом случае мы можем использовать исключение во время выполнения или обернуть исключение как непроверенное исключение.

Исключение во время выполнения используется, когда с наибольшей вероятностью произойдет исключение, дальше идти невозможно и ничто не может быть восстановлено.Таким образом, в данном случае мы можем принять меры предосторожности в отношении этого исключения.БЫВШИЙ:Исключение NullPointerException, исключение ArrayOutOfBoundsException.Это более вероятно, что произойдет.В этом сценарии мы можем принять меры предосторожности при кодировании, чтобы избежать такого исключения.В противном случае нам придется писать блоки try catch везде.

Более общие исключения можно сделать непроверенными, менее общие проверяются.

Я думаю, мы можем подумать об исключениях из нескольких вопросов:

почему происходит исключение?Что мы можем сделать, когда это произойдет

по ошибке, ошибка. например, вызывается метод нулевого объекта.

String name = null;
... // some logics
System.out.print(name.length()); // name is still null here

Такого рода исключения должны быть исправлены во время тестирования.В противном случае это приведет к сбою в работе, и вы получите очень серьезную ошибку, которая должна быть немедленно исправлена.Такого рода исключения проверять не нужно.

по входному сигналу из внешнего, вы не можете контролировать выходные данные внешней службы или доверять им.

String name = ExternalService.getName(); // return null
System.out.print(name.length());    // name is null here

Здесь вам может потребоваться проверить, является ли имя null, если вы хотите продолжить, когда оно равно null, в противном случае вы можете оставить его в покое, и оно остановится здесь и выдаст вызывающему исключение во время выполнения.Такого рода исключения проверять не нужно.

по исключению во время выполнения из внешнего, вы не можете контролировать внешнюю службу или доверять ей.

Здесь вам может потребоваться перехватить все исключения из ExternalService, если вы хотите продолжить, когда это произойдет, в противном случае вы можете оставить это в покое, и оно остановится здесь и выдаст вызывающему исключение во время выполнения.

проверенным исключением из внешнего, вы не можете контролировать внешнюю службу или доверять ей.

В этом случае, нужно ли нам знать, какое исключение произошло во ExternalService? Это зависит:

если вы можете обрабатывать некоторые виды исключений, вам нужно перехватить их и обработать.Для других - надувайте их пузырями.
если вам нужен журнал или ответ пользователю на конкретное выполнение, вы можете перехватить их.Для других - надувайте их пузырями.

Мы должны различать эти два типа исключений в зависимости от того, является ли это ошибкой программиста или нет.

Если ошибка является ошибкой программиста, это должно быть Непроверенное исключение. Например:Исключение SQLException/IOException/NullPointerException.Этими исключениями являются ошибки программирования.Они должны обрабатываться программистом.В то время как в JDBC API SQLException является проверяемым исключением, в Spring JdbcTemplate это непроверенное исключение.Программист не беспокоится о SQLException, когда использует Spring.
Если ошибка не является ошибкой программиста и причина исходит извне, это должно быть Проверенное исключение. Например:если файл удален или разрешение на доступ к файлу изменено кем-либо другим, его следует восстановить.

FileNotFoundException - хороший пример для понимания тонких различий.FileNotFoundException выдается в случае, если файл не найден.Есть две причины для этого исключения.Если путь к файлу определен разработчиком или взят у конечного пользователя через графический интерфейс, это должно быть Непроверенное исключение.Если файл удален кем-то другим, это должно быть Проверенное исключение.

Проверенное исключение может быть обработано двумя способами.Они используют try-catch или распространяют исключение.В случае распространения исключения все методы в стеке вызовов будут тесно связанный из-за обработки исключений.Вот почему мы должны осторожно использовать проверяемое исключение.

В случае, если вы разрабатываете многоуровневую корпоративную систему, вы должны выбрать в основном непроверенное исключение для выброса, но не забудьте использовать проверенное исключение на случай, если вы ничего не можете сделать.

Я думаю, что при объявлении исключения приложения это должно быть Непроверенное исключение, т.е. подкласс RuntimeException.Причина в том, что это не будет загромождать код приложения с помощью try-catch и бросает объявление в метод.Если ваше приложение использует Java Api, который выдает проверенные исключения, которые в любом случае необходимо обработать.В других случаях приложение может выдавать непроверенное исключение.Если вызывающему приложению все еще необходимо обработать непроверенное исключение, это можно сделать.

Правило, которое я использую, таково:никогда не используйте непроверенные исключения!(или когда вы не видите никакого способа обойти это)

С точки зрения разработчика, использующего вашу библиотеку, или конечного пользователя, использующего вашу библиотеку / приложение, действительно неприятно сталкиваться с приложением, которое выходит из строя из-за неперехваченного исключения.И рассчитывать на универсальность тоже нехорошо.

Таким образом, конечному пользователю все равно может быть выдано сообщение об ошибке, вместо того чтобы приложение полностью исчезло.

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow