Чи все-таки антипатерн, якщо ми записуємо повідомлення про виняток і кидаємо інше виняток?


18

У нашому веб-застосуванні використовується 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();
  }
}

3
Я зупинив би вас, як тільки ви ввійшли в систему ex.getMessage(), це вже неправильно.
biziclop



IMO не дуже справедливо взагалі не згадувати, що це веб-сервіс. Це насправді змінює правила гри, тому що, наприклад, використання звичайних механізмів обробки виключень може становити загрозу безпеці; Ви не хочете, щоб будь-який виняток був просто відправлений назад у відповіді на помилку 500, яку потрібно перевірити і відфільтрувати. Агресивна реєстрація на місцях також набагато частіше зустрічається при роботі із системами, у яких зовнішні клієнти безпосередньо звертаються до неї. Реєстрація стек-треків у службових викликах, які викликаються неодноразово, може призвести до некерованих розмірів файлів журналу та проблем з продуктивністю.

@Gimby У цьому випадку ОП не надсилає жодних деталей помилок у відповіді (ймовірно, вміст "помилки" виявився на коробці). Крім того, як діагностувати проблему без стеження? Рулонні реєстратори регулярно дбають про розмір пам’яті, а дані журналу незбагненно стискаються.
Марко Тополник

Відповіді:


36

Ваш код насправді містить не один, а три анти-візерунки:

  1. журнал і повторне відкидання;
  2. повторне відкидання, не загортаючи первісну причину;
  3. записуйте тільки повідомлення, а не стежку (це найгірше).

Якщо ви дотримувались найкращої практики:

  1. зовсім не ловити (нехай виняток поширюється самостійно);
  2. якщо змушений зловити перевірений виняток, загорнутись у неперевірений та повторно скинути;
  3. ніколи не реєструйте нічого, крім самого верхнього рівня;
  4. записуйте весь стек-тракт винятку за допомогою log.error("Error occurred", e);

тоді ви не зіткнетеся з будь-якими дилемами, включаючи поточну, тому що зареєстрована стек-тракція міститиме і всі завершені винятки.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.