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

голоса
9

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

emailUtil.sendEmail(userId, foo);

public void sendEmail(String userId, String message) throws MailException {
    /* ... logic that could throw a MailException */
}

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

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

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

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

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

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


11 ответов

голоса
10

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

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

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

общественный BOOL isEmailConfigured ()

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

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

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

Ответил 22/08/2008 в 04:07
источник пользователем

голоса
8

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

Пример из Java-API является IOException, который имеет подклассы, как FileNotFoundException или EOFException (и многое другое).

Таким образом, вы получаете преимущества обоих, вы не имеете вбрасывание положения, как:

throws SpecificException1, SpecificException2, SpecificException3 ...

генерал

throws GeneralException

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

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

голоса
2

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

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

Ответил 11/01/2009 в 20:28
источник пользователем

голоса
2

@ Chris.Lively

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

Ответил 22/08/2008 в 05:46
источник пользователем

голоса
1

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

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

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

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

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

голоса
1

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

Вызывающий код затем решить, какой фильтр до UI и который для обработки себя.

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

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

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

UPDATE: объединение ответы

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

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

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

Ответил 22/08/2008 в 05:35
источник пользователем

голоса
1

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

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

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

Ответил 22/08/2008 в 04:00
источник пользователем

голоса
0

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

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

голоса
0

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

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

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

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

голоса
0

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

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

Ответил 22/08/2008 в 06:42
источник пользователем

голоса
-1

Я бы просто пойти по

throw new exception("WhatCausedIt")

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

Ответил 22/08/2008 в 06:48
источник пользователем

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