JnDev
@JnDev
Inquisitive

Чистый код: блоки try/catch. Стоит ли так делать?

Читаю Рики Роберта Мартина - "Чистый Код". И до сих пор думаю об одном его совете, с которым мне тяжело согласиться. Мартин советует изолировать блоки try/catch, т.е. всю область, что находится в блоке try выделить в ОДИН отдельный метод. Например, вот такой довольно лаконичный и легко читаемый метод:
public void delete(Page page)
{
  try {
    deletePage(page);
    registry.deleteReference(page.name);
    configKeys.deleteKey(page.name.makeKey());
  } catch (Exception e) {
    logger.log(e.getMessage());
  }
}

Мартин предлагает преобразовать в два метода:

public void delete(Page page)
{
  try {
    deletePageAndAllReferences(page);
  } catch (Exception e) {
    logger.log(e.getMessage());
  }
}

private void deletePageAndAllReferences(Page page)
{
  deletePage(page);
  registry.deleteReference(page.name);
  configKeys.deleteKey(page.name.makeKey());
}

Мартин говорит, что таким образом мы отделяем бизнес-логику от обработки ошибок.

Но, мне кажется, это избыточно. Да, разумеется, если у нас в try {} сложная логика то ее следует декомпозировать, но если у нас в try {} несколько понятных вызовов методов, то разве нужно выделять их в один метод? Тем более, становится сложно придумать РАЗНЫЕ названия для двух методов, которые делают по сути одно и то же. При этом, сам же Мартин очень большой акцент делает на хорошем и не запутывающем именовании методов.

Как считаете, стоит ли так делать? И следуете ли вы сами такому примеру?
  • Вопрос задан
  • 3320 просмотров
Решения вопроса 2
Adamos
@Adamos
Я бы сказал, применимость такого правила сильно зависит от того, приходится ли вам, читая обработку исключений, лезть в код того, что их вызвало.
Если код выплевывает исключения, которые полностью понятны без чтения этого кода - можно его завернуть в функцию и убрать с глаз долой.
Если же исключительные ситуации связаны с самой логикой метода, то размазывание этой логики по разным функциям просто нелепо.
Ответ написан
Комментировать
FanatPHP
@FanatPHP
Чебуратор тега РНР
> если у нас в try {} несколько понятных вызовов методов,

причем таких как в примере, далеющих только логирование, и поэтому повторающихся сотни и тысячи раз, то try catch в таеом случае писать не нужно вообще. А добавить либо глобальный трай для всего приложение, либо написать отдельный хендлер/обработчки исключений, если язык позволяет.

То есть ответ на вопрос очевиден:

- если у нас в кетче только логинование, то трай не пишем вовсе
- если в кетче замороченная логика, то трай разумеется имеет смысл вынести в отдельный метод
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 6
@heartdevil
плыву как воздушный шарик
Если думаете, что избыточно, то не делайте, как он советует. Возможно, в вашей конкретной ситуации так и есть. А далее чутье или горький опыт подскажет где надо выделять обработку ошибок, а где нет.
Ответ написан
Комментировать
Arris
@Arris
Сапиенсы учатся, играя.
Я не гуру джавы, но здравый смысл подсказывает мне, что механика исключений не спасёт вас от ошибок, если применять её направо и налево без понимания, когда и зачем она нужна. Это не волшебная палочка безошибочного кода, это инструмент. Его надо уметь применять.

Сдается мне (я опять же не гуру джавы), что можно прекрасно обойтись без этого механизма, просто сахара будет меньше и сложность поддержки возрастет.
Ответ написан
Комментировать
Umr001
@Umr001
php
Думаю мартин ровно черкает иначе бы попустили бедолагу
Ответ написан
Комментировать
@4iloveg
Full-Stack HTML Developer
Может в книге не стали писать объемный код как пример, а записали короткий и по этому у вас сомнения.
Если 3 строки то Мартин и сам, может не стал бы выносить его в метод. Но если речь идет о большем объеме кода в блоке, то совет не будет лишним.
Главное в коде что бы его можно было легко понять. Т.е. прочитать название метода быстрее чем разобраться что он делает.
Ответ написан
@plohish
а в чём именно сложность именований методов в такой ситуации?
в данном примере кто мешает назвать например так:
public void tryDelete(Page page)
и
private void delete(Page page)
Ответ написан
profesor08
@profesor08
Принцип разделяй и властвуй. Запомни! И делай как автор советует.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
Bell Integrator Ульяновск
До 400 000 ₽
Bell Integrator Ижевск
До 400 000 ₽
Bell Integrator Хабаровск
До 400 000 ₽
28 мар. 2024, в 18:16
1000 руб./за проект
28 мар. 2024, в 18:15
90000 руб./за проект
28 мар. 2024, в 18:05
5000 руб./за проект