Обработка исключений в отдельном методе для удобочитаемости

Это анти-шаблон для обработки исключений в отдельном методе?

Скажем, у меня есть метод, который выполняет низкоуровневый ввод-вывод и может вызвать исключение IOException, и у меня есть метод foo(), который несколько раз вызывает низкоуровневый метод ввода-вывода. Имеет ли смысл выполнять обработку исключений в третьем методе следующим образом:

 public void foo()  throws MyCheckedException {
     // some stuff
     goDoSomeIO(path1)
    // some other stuff
     goDoSomeIO(path2)
    // some more stuff
     goDoSomeIO(path3)

  }

 private String goDoSomeIO(String filePath) throws MyCheckedException {
     try {
         doSomeIO(filePath);
     } catch (IOException ioe) {
         LOG.error("Io failed at: " + filePath);
         throw new MyCheckedException("Process failed because io failed", ioe)
     }
  }

 private String doSomeIO(String filepath) throws IOException {
        //io stuff
  }

Я считаю, что это более читабельно, чем если бы метод doSomeIO выполнял собственную обработку исключений или если бы обработка исключений происходила в foo.

это вопрос стиля и зависит от ситуации

firephil 27.03.2019 16:37
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
2
1
341
2

Ответы 2

Общее правило перехвата исключения [checked] состоит в том, чтобы делать это, когда вы можете восстановиться из возникшей «исключительной» ситуации. Если вы не можете восстановиться после исключения здесь, позвольте ему подняться до уровня, при котором оно могу будет восстановлено. Например, уведомите пользователя о том, что выбранный файл не читается, и разрешите пользователю снова выбрать файл. Или отправить запросившему «страницу» 404, когда фактически запрошенная страница не существует.

Эффективная Java, пункт 58

Обычно используемым исключением из этого правила является перехват, выполнение некоторой тривиальной работы без восстановления (например, ведение журнала) и повторное создание исключения (возможно, в оболочке). Не вижу ничего плохого в вашем подходе.

На самом деле это про-шаблон для добавления дополнительных деталей к исключению и его повторного генерирования.

Я часто вижу код, который обрабатывает исключения методов более низкого уровня на более высоком уровне, независимо от того, является ли более низкий уровень одним методом или несколькими.

Это довольно распространено и связано с отдельными проблемами: низкоуровневый материал заботится о передаче файлов, высокоуровневый материал перехватывает исключения, чтобы определить, сработала ли сложная операция или нет. Я не думаю, что есть что-то неправильное в том, чтобы обрабатывать ввод-вывод и обрабатывать ввод-вывод разными методами. (Я бы попытался дать им какое-нибудь имя, которое, однако, объясняет цель. Я не фанат goDoWhatever и doWhatever)

Упс, извините, слишком быстро читал. Только что видел лог. Отредактирую мой ответ.

froh42 27.03.2019 16:48

Спасибо, +1 за «дайте ему имя, объясняющее цель».

Ivana 27.03.2019 17:02

Другие вопросы по теме