Когда выбирать отмеченные и непроверенные исключения - PullRequest
186 голосов
/ 26 августа 2008

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

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

Ответы [ 18 ]

2 голосов
/ 24 марта 2013

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

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

2 голосов
/ 30 июня 2017

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

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

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

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

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

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

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

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

1 голос
/ 27 июля 2018

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

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

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

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

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

1 голос
/ 16 октября 2015

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

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

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

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. если вам нужен лог или ответ пользователю конкретного исполнения, вы можете их перехватить. Для других, пузырь их.

1 голос
/ 26 августа 2008

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

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

1 голос
/ 06 февраля 2014

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

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

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

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

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

0 голосов
/ 09 мая 2017

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

0 голосов
/ 26 августа 2008

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

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

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

...