У нашому веб-застосуванні використовується ExceptionMapper
для відображення деяких винятків Response
. Ми записуємо повідомлення про винятки перед тим, як викидати новий виняток наступним чином:
catch (SomeException ex) {
LOG.error(ex.getMessage());
throw new MyException(ex.getMessage());
}
Ми не перекидаємо той самий виняток , тому моє запитання полягає в тому, чи вважали б це антипаттером журналу та кидання . Таким чином, було б краще прибрати журнал в подібних місцях і перемістити їх у кілька ExceptionMapper
класів наступним чином:
@Provider
public class MyExceptionMapper implements ExceptionMapper<MyException> {
// bla bla
@Override
public Response toResponse(final MyException ex) {
LOG.error(ex.getMessage());
return Response.status(400).entity("something").build();
}
}
можливий дублікат: Якщо ви повідомляєте текст повідомлення про винятки?
Сперечатися, повідомляти про текст повідомлення про винятки - це завжди погана ідея .
IMO не дуже справедливо взагалі не згадувати, що це веб-сервіс. Це насправді змінює правила гри, тому що, наприклад, використання звичайних механізмів обробки виключень може становити загрозу безпеці; Ви не хочете, щоб будь-який виняток був просто відправлений назад у відповіді на помилку 500, яку потрібно перевірити і відфільтрувати. Агресивна реєстрація на місцях також набагато частіше зустрічається при роботі із системами, у яких зовнішні клієнти безпосередньо звертаються до неї. Реєстрація стек-треків у службових викликах, які викликаються неодноразово, може призвести до некерованих розмірів файлів журналу та проблем з продуктивністю.
@Gimby У цьому випадку ОП не надсилає жодних деталей помилок у відповіді (ймовірно, вміст "помилки" виявився на коробці). Крім того, як діагностувати проблему без стеження? Рулонні реєстратори регулярно дбають про розмір пам’яті, а дані журналу незбагненно стискаються.
—
Марко Тополник
ex.getMessage()
, це вже неправильно.