Шаблон обработки исключений

Question

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

можно найти довольно обширную коллекцию общих и полезных шаблонов.

Answer 3

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

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

Answer 4

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