Рекомендации по распространению исключений (в Java)

Рекомендации, которые помогли мне в прошлом, включают:

• Выбрасывать исключения, когда метод не может обработать исключение , и, что более важно, должен обрабатываться вызывающим. Хороший пример этого присутствует в API сервлета - doGet () и doPost () вызывают исключение ServletException или IOException в определенных обстоятельствах, когда запрос не может быть правильно прочитан. Ни один из этих методов не может обработать исключение, но контейнер умеет (что в большинстве случаев приводит к отображению страницы ошибки 50x).
• Обрезать исключение, если метод не может его обработать . Это следствие вышеизложенного, но применимо к методам, которые должны перехватывать исключение. Если перехваченное исключение не может быть правильно обработано методом, то предпочтительнее перебросить его в пузырь.
• Немедленно выбросить исключение . Это может показаться расплывчатым, но если встречается сценарий исключения, то рекомендуется генерировать исключение, указывающее исходную точку отказа, вместо попытки обработать сбой с помощью кодов ошибок, до тех пор, пока точка не будет сочтена подходящей для создания исключения. . Другими словами, постарайтесь свести к минимуму смешивание обработки исключений с обработкой ошибок.
• Либо зарегистрируйте исключение, либо закройте его, но не делайте и того, и другого . Регистрация исключения часто указывает на то, что стек исключений был полностью размотан, что указывает на то, что дальнейшего всплытия исключения не произошло.Следовательно, не рекомендуется делать и то и другое одновременно, так как это часто приводит к разочарованию при отладке.
• Используйте подклассы java.lang.Exception (отмеченные исключения), когда вы исключаете вызывающий объект для обработки исключения . Это приводит к тому, что компилятор выдает сообщение об ошибке, если вызывающий объект не обрабатывает исключение. Однако будьте осторожны, это обычно приводит к тому, что разработчики «проглатывают» исключения в коде.
• Используйте подклассы java.lang.RuntimeException (непроверенные исключения), чтобы сигнализировать об ошибках программирования . Классы исключений, которые здесь рекомендуются, включают IllegalStateException , IllegalArgumentException , UnsupportedOperationException и т. Д. практика бросать один).
• Используйте иерархии классов исключений для передачи информации об исключениях на различных уровнях . Реализуя иерархию, вы можете обобщить поведение обработки исключений в вызывающей программе. Например, вы можете использовать корневое исключение, такое как DomainException, которое имеет несколько подклассов, таких как InvalidCustomerException, InvalidProductException и т. Д. Предостережение заключается в том, что ваша иерархия исключений может очень быстро взорваться, если вы представляете каждый отдельный исключительный сценарий как отдельное исключение.
• Избегайте перехвата исключений, которые вы не можете обработать . Довольно очевидно, но многие разработчики пытаются перехватить java.lang.Exception или java.lang.Throwable.Поскольку все исключения подкласса могут быть перехвачены, поведение приложения во время выполнения часто может быть неопределенным, когда перехватываются «глобальные» классы исключений. В конце концов, никто не захочет поймать OutOfMemoryError - как следует обрабатывать такое исключение?
• Переносить исключения с осторожностью . Повторное отображение исключения сбрасывает стек исключений. Если исходная причина не была предоставлена ​​новому объекту исключения, он теряется навсегда. Чтобы сохранить стек исключений, нужно будет предоставить исходный объект исключения конструктору нового исключения.
• Преобразовывать отмеченные исключения в непроверенные только при необходимости . При обертывании исключения можно обернуть проверенное исключение и выбросить непроверенное. Это полезно в определенных случаях, особенно когда намерение состоит в том, чтобы прервать выполняющийся в данный момент поток. Однако в других сценариях это может вызвать небольшую боль, поскольку проверки компилятора не выполняются. Следовательно, адаптация отмеченного исключения как непроверенного не должна выполняться вслепую.