Вы пишете исключения для конкретных вопросов или общие исключения?

В моем коде я нахожу, что БОЛЬШИНСТВО исключений проникает до уровня UI, где они пойманы моими обработчиками исключений, которые просто отображают сообщение пользователю (и пишут в журнал). Это - непредвиденная исключительная ситуация, в конце концов.

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

Так с помощью примера, если Вы хотите выполнить некоторую специальную логику, когда почтовый сервер не настроен, можно хотеть добавить метод к объекту emailUtil как:

общедоступный bool isEmailConfigured ()

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

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

Что касается наличия иерархии исключения по сравнению с exceptions-with-error-codes-in-them, я обычно делаю последнего. Легче добавить новые исключения, если просто необходимо определить новую ошибку, постоянную вместо совершенно нового класса. Но, это не имеет значения, пока Вы пытаетесь быть последовательными в течение своего проекта.

@Chris. Живой

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

Я нашел что, если у Вас должен быть КОД, решающий, что сделать на основе возвращенного исключения, создать хорошо именованное исключение, разделяющее тип общей базы на подклассы. Сообщение передало, должен считаться "человеческими глазами только" и слишком хрупкий для принятия решений о. Позвольте компилятору сделать работу!

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

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

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

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

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

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

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

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

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

Код вызова затем решил бы, чтобы отфильтровать до UI и чтобы обработать себя.

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

Другая причина использования списка объектов состояния состоит в том, что идентификация нескольких ошибок (такой как во время проверки) НАМНОГО легче. В конце концов, можно только выдать одно исключение, которое должно быть обработано перед хождением дальше.

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

ОБНОВЛЕНИЕ: объединение ответов

@Jonathan: Моя точка была то, что я могу оценить действие, в этом случае, посылающем электронное письмо, и передать причины многократного отказа обратно. Например, "плохой адрес электронной почты", "очищают заголовок сообщения", и т.д.

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

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

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

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

В то время как Вы можете differenciate выполнение кода, выглядящее, исключением не имеет значения, сделано ли это "выгодой exceptionType режим иерархии" или "если (...) еще... режим кода исключения"

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

Когда я пользуюсь библиотекой, и их методы просто запускают 'Исключение', я всегда задаюсь вопросом: Что может вызвать это исключение?, как моя программа должна реагировать?, если будет javadoc, возможно, то причина будет объяснена, но mustly времен нет javadoc, или исключение не объяснено. Слишком большого количества служебной ведьмы можно избежать с WellChossenExceptionTypeName

Я просто прошел бы

throw new exception("WhatCausedIt")

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

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