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

голоса
152

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

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

Задан 26/08/2008 в 09:45
источник пользователем
На других языках...                            


18 ответов

голоса
161

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

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

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

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

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

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

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

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

Ответил 27/09/2013 в 23:32
источник пользователем

голоса
51

От обучающегося Java :

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

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

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

Ответил 26/08/2008 в 09:51
источник пользователем

голоса
45

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

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

Ответил 26/08/2008 в 10:30
источник пользователем

голоса
33

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

С проверяемых исключениями вашей обработки ошибок микро СТРАТЕГИЯ-управлением и невыносимая на любой крупной системе.

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

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

В этом случае абонент АФИ не хочет, чтобы поймать исключение. Он только хочет, чтобы исключение «пузыриться». Если я выбрал проверяемое исключение, этот абонент будет иметь много бесполезных поймать блок только искусственно повторно выдать исключение.

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

Ответил 17/09/2008 в 22:19
источник пользователем

голоса
26

Вы правы.

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

Например:

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

И вы будете знать, что произошло. OtherClass в методе «delegateTheWork» (в строке 4569) назвал свой класс со значением «выход», даже если оно не должно и т.д.

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

То же самое происходит и с 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 
      ....
  }

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

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

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

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

Ответил 27/11/2008 в 04:44
источник пользователем

голоса
17

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

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

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


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

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

  • контейнер объекта , чтобы сделать / получить должен существовать (ответственность CALLER
    => бесконтрольно исключение, и ясно Javadoc комментарий для этой вызываемой функции)
  • остальные параметры не могут быть нулевым
    (выбор кодере положить , что на CALLER: кодировщик не будет проверять параметр нулевого , но кодировщик НЕ документ)
  • результат не может быть нулевым
    (ответственность и выбор кода вызываемого абонента, выбор , который будет представлять большой интерес для вызывающего абонента
    => проверяемое исключение , потому что каждый звонящий должен принять решение , если объект не может быть создан / найден, и что решение должно быть исполнено в то время компиляции: они не могут использовать эту функцию без необходимости иметь дело с этой возможностью, то есть с этим проверяемым исключением).

Пример:


/**
 * 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;
}
Ответил 16/09/2008 в 16:06
источник пользователем

голоса
15

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

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

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

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

Ответил 27/11/2008 в 03:29
источник пользователем

голоса
8

Вот очень простое решение для вашей зарегистрированной / незарегистрированной дилеммы.

Правило 1: Думайте о незарегистрированном Exception как проверяемое состояние до выполнения кода. например…

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

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

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, который изобрел эту концепцию.

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

Существует серая зона для этого. В том случае, если многие тесты необходимы (сногсшибательный, если заявление с большим количеством && и ||), исключение брошено будет CheckedException просто потому, что это слишком много боли, чтобы получить право - вы просто не можете сказать, эта проблему ошибка программирования. Если есть намного меньше, чем 10 тестов (например, «если (х == NULL)»), то ошибка программиста должна быть UncheckedException.

Все становится интересно, когда дело с языком переводчиками. В соответствии с вышеуказанными правилами, должна синтаксическая ошибка считать зарегистрированным или незарегистрированным Exception? Я считаю, что если синтаксис языка может быть проверена, прежде чем она будет выполнена, она должна быть UncheckedException. Если язык не может быть проверен - аналогично тому, как сборка код выполняется на персональном компьютере, то ошибка синтаксиса должна быть проверено Exception.

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

Ответил 03/05/2014 в 03:58
источник пользователем

голоса
8

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

Ответил 12/07/2011 в 10:40
источник пользователем

голоса
7

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

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

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

См здесь

Ответил 19/12/2012 в 02:05
источник пользователем

голоса
2

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

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

Ответил 24/03/2013 в 19:47
источник пользователем

голоса
1

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

  1. Проверено исключение. Это является частью бизнес-прецедента или потока вызовов, это часть логики приложения мы ожидаем или не ожидать. Для примера соединение отвергается, условие не выполнено и т.д. Мы должны справиться с этим и показать соответствующее сообщение пользователя с указанием того, что произошло и что делать дальше (повторите попытку позже и т.д.). Я обычно называю это исключение постобработки или «пользователь» исключение.

  2. Неконтролируемое исключение. Это является частью программирования исключения, то ошибка в программном обеспечении кода программирования (ошибка, дефект) и отражает способ, как программисты должны использовать API в соответствии с документацией. Если внешний Lib / рамки документ говорит, что рассчитывает получить данные в некотором диапазоне и не нулевой, так как NPE или IllegalArgumentException будут выброшены, программист должен ожидать его и использовать API правильно в соответствии с документацией. В противном случае будет сгенерировано исключение. Я обычно называю это исключение предварительной обработки или «проверка» исключение.

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

  1. Проверено исключение. Целевая аудитория пользователей / клиентов.
  2. Неконтролируемое исключение. Целевая аудитория разработчики. Иными словами бесконтрольно исключение предназначены только для разработчиков.

На стадии жизненного цикла разработки приложений.

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

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

Ответил 30/06/2017 в 15:34
источник пользователем

голоса
1

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

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

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

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

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

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

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

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

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

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

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

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

Ответил 16/10/2015 в 09:36
источник пользователем

голоса
1

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

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

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

Продолжительность исключения используется, когда исключение, скорее всего, будет произошло, нет никакой возможности идти дальше и ничто не может быть возмещена. Так что в этом случае мы можем принять меры в отношении этого исключения. EX: NullPointerException, ArrayOutofBoundsException. Это более вероятно, произойдет. В этом случае, мы можем принять меры предосторожности во время кодирования, чтобы избежать такого исключения. В противном случае нам придется писать попробовать ловить блоки, где каждый.

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

Ответил 06/02/2014 в 10:29
источник пользователем

голоса
1

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

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

Ответил 26/08/2008 в 10:13
источник пользователем

голоса
0

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

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

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

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

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

Ответил 27/07/2018 в 10:39
источник пользователем

голоса
0

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

Ответил 09/05/2017 в 15:21
источник пользователем

голоса
-12

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

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

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

Ответил 26/08/2008 в 09:57
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more