2011-01-04 5 views
11

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

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

Есть ли золотая середина? Каков рекомендуемый метод?

+1

http://weblogs.java.net/blog/bakksjo/archive/2005/09/java_exception.html – drifter

ответ

6

Это хороший вопрос. Я считаю, что есть определенная точка зрения.

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

Для программной обработки ошибок я лично не рекомендую коды ошибок, я бы рекомендовал новый класс для каждой категории ошибок, но определенно не для каждой отдельной ошибки. Java позаботилась о том, чтобы мы начали с Исключения, такие как IOException, IllegalArgumentException, UnsupportedOperationException и т. Д. Я часто бросаю и ловить их, когда это необходимо в моем коде.

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

+0

вот что я склоняюсь, хорошо слышать это от кого-то другого. Мне нужен общий способ для ops, qa и development, чтобы говорить об ошибках и кодах ошибок, похоже, что-то. – treefrog

5

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

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

+0

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

+0

@treefrog - вы можете приблизительно догадаться. И чем меньше у вас есть уверенности в том, что «все эти исключения будут обрабатываться почти одинаково», тем больше у них будет подход с разными классами исключений. – DVK

1

«Средняя земля», как я вижу, заключается в использовании внутренних «кодов ошибок» (общий шаблон, но не ОЧЕНЬ распространенный, ИМО) в качестве дополнительной информации для целей отчетности/информации; но не для определения того, кто ловит исключение (это определяется классом исключения).

+0

Я склонен согласиться. – treefrog

5

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

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

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

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

+0

очень полезная ссылка! спасибо, что я забыл о репозитории шаблонов – treefrog

Смежные вопросы