Есть несколько правил обработки исключений, которые вы должны иметь в виду. Но сначала вы должны помнить, что исключения являются частью интерфейса, предоставляемого кодом; документировать их . Это особенно важно, когда интерфейс общедоступен, конечно, но это очень хорошая идея и для частных интерфейсов.
Исключения следует обрабатывать только в том месте, где код может сделать что-то разумное с ними. Худший вариант обработки - ничего с ними не делать, что следует делать только тогда, когда это абсолютно правильный вариант. (Когда в моем коде возникает такая ситуация, я добавляю комментарий на этот счет, чтобы не беспокоиться о пустом теле.)
Второй худший вариант - выбросить несвязанное исключение без указания причины. Проблема здесь в том, что информация в исходном исключении, которая позволила бы диагностировать проблему, потеряна; вы создаете что-то, с чем никто ничего не может сделать (кроме как жаловаться, что «это не работает», и мы все знаем, как мы ненавидим эти сообщения об ошибках).
Гораздо лучше регистрировать исключения. Это позволяет кому-то выяснить, в чем заключается проблема, и устранить ее, но вы должны регистрировать исключение только в том месте, где в противном случае оно будет потеряно или передано по внешнему соединению. Это не потому, что ведение журнала чаще всего является серьезной проблемой, а скорее потому, что чрезмерное ведение журнала означает, что вы просто получаете журнал, занимающий больше места без дополнительной информации. После того, как вы вошли исключение, вы можете сообщить PRECIS к пользователю / клиента с чистой совестью ( до тех пор , как вы можете также включать в себя время генерации - или другой идентификатор корреляции - в этом докладе , так что короткая версия может быть подобран с детализацией при необходимости).
Конечно, наилучший вариант - полностью обработать исключение, полностью устраняющее ситуацию с ошибками. Если вы можете сделать это, во что бы то ни стало сделайте это! Это может даже означать, что вы можете избежать регистрации исключения.
Одним из способов обработки исключения является создание другого исключения, которое предоставляет описание проблемы более высокого уровня (например, « failed to initialize» вместо « index out of bounds»). Это хороший шаблон, если вы не потеряете информацию о причине исключения; используйте подробное исключение, чтобы инициализировать исключение causeболее высокого уровня или зарегистрируйте подробности (как обсуждалось выше). Ведение журнала наиболее уместно, когда вы собираетесь пересечь межпроцессную границу, такую как вызов IPC, потому что нет никакой гарантии, что низкоуровневый класс исключений будет вообще присутствовать на другом конце соединения. Хранение в качестве прикрепленной причины наиболее целесообразно при пересечении внутренней границы.
Другой шаблон, который вы видите, это «поймай и отпусти»:
try {
// ...
} catch (FooException e) {
throw e;
}
Это анти-шаблон, если у вас нет ограничений типа из других catchпредложений, которые означают, что вы не можете просто позволить исключению пройти самостоятельно. Тогда это просто уродливая особенность Java.
Нет реальной разницы между проверенными исключениями и непроверенными, за исключением того факта, что вы должны объявлять проверенные исключения, которые пересекают границы метода. Хорошей идеей будет документировать неконтролируемые исключения (с @throwsкомментариями javadoc), если вы знаете, что они намеренно генерируются вашим кодом. Не преднамеренно выбрасывайте java.lang.Errorили его подклассы (если вы не пишете реализацию JVM).
Мнение: случай непредвиденной ошибки всегда представляет ошибку в вашем коде. Проверенные исключения являются способом управления этой угрозой, и когда разработчики намеренно используют непроверенные исключения как способ избежать проблем с обработкой ошибок, вы накапливаете большой технический долг, который вам придется некоторое время устранять. если вы хотите надежный код. Небрежная обработка ошибок непрофессиональна (и рассмотрение обработки ошибок - хороший способ определить, насколько хорош программист на самом деле).