Является ли следующий способ написания кода хорошей практикой?
try {
//my code here
} catch (Exception e) {
logger.error("Some error ", e);
throw new MyCustomException("Some error ", e);
}
Более того, я должен..
Я понимаю, что с помощью throw я могу перехватить исключение в другой части стека вызовов, но, возможно, дополнительное ведение журнала имеет некоторые скрытые преимущества и также полезно.
Я использую оба в некоторых случаях, входя в систему и бросая исключение. Особенно это полезно в API. Вызывая исключение, мы позволяем вызывающей стороне справиться с ним, и, ведя журнал, мы можем сами определить его причину.
И, если вызывающая сторона находится в той же системе, то, если мы добавим логи в каждом улове, будут дублироваться логи.
Обычно я утверждаю, что вам нужно либо зайти в журнал, либо перебросить. Выполнение обоих действий приведет к тому, что каждый слой будет регистрировать исключение снова и снова, что затрудняет чтение журналов. Хуже того, трудно понять, сколько ошибок вы на самом деле имеете - было ли это семь ошибок или семь слоев приложения, которые регистрировали одну и ту же ошибку?
Это означает, что , если вы подавляете исключение, вы регистрируете его и говорите, почему вы не думали, что это стоило реконструировать.
С другой стороны, если вы повторно выбрали исключение, вы знаете, что он либо будет пойман, либо подавлен (в этом случае ловец регистрирует исключение и почему он был подавлен), или он выйдет из вашего приложения и попадет в контейнер приложения, который поймает и зарегистрирует исключение. Каждое исключение появляется один раз и только один раз в журналах.
При использовании шаблона, который вы предлагаете, вы обычно получаете сообщения об ошибках, сообщаемые несколько раз в журнале. Кроме того, при чтении журнала не всегда легко соединяться между собой.
Лично я предпочитаю регистрировать ошибки только один раз и делать это в более высоких уровнях вызовов. Поэтому я почти никогда не регистрирую и не перебрасываю. Обычно я допускаю исключение в стек вызовов до тех пор, пока не достигнет контекста, где его можно каким-то образом обработать, и именно там я запишу.
Если исключения завернуты и переброшены правильно, контекст должен быть совершенно ясным из трасс стека одного сообщения журнала.
Правильный ответ: "это зависит"
Вы вообще хотите регистрировать исключения, которые вы улавливаете, поскольку они соответствуют тому, что происходит неправильно. Вот почему инструменты анализа кода, такие как сонар, будут вызывать предупреждения, когда вы их не регистрируете.
Рассмотрим следующие taks: синтаксический анализ файла. При анализе файла вы пытаетесь проанализировать каждую строку. Иногда некоторые строки будут искажены, и поэтому вы не хотите прекращать разбор файла из-за этого. В этом случае вы, вероятно, хотите просто записать неверную строку и продолжить работу с файлом. Однако представьте себе, что в какой-то момент вы сталкиваетесь с исключением I/O при чтении (например, какая-то другая программа удалила файл, пока ваш доступ к нему).
В этом случае вам, вероятно, захочется записать в журнал ошибку, с которой вы столкнулись, и выбросить новое исключение, чтобы остановить обработку всего файла.
Итак, вы должны подумать о том, что лучше всего делать. Но обе практики неплохие.
Думаю, вам может понадобиться использовать шаблон разумно. Как вы уже написали выше, для каждого исключения вы собираетесь регистрировать 2 стека и можете заполнить ваши журналы чрезмерной информацией.
Что касается ведения журнала или броска, это две отдельные проблемы. Выброс исключения прерывает выполнение, предотвращает дальнейшую работу, возможно, откатывает базу данных и т.д. Ведение журнала просто выдает информацию в файл журнала (или в другом месте). Это больше подходит для отладки и часто гораздо сложнее проверить.