Максим

Bill Karwin SQL Antipatterns
В общем-то, в духе рефакторинга как раз: как делают часто неправильно, почему это плохо (но когда и адекватно для задачи) и как сделать лучше.

Я бы сказал, применимость такого правила сильно зависит от того, приходится ли вам, читая обработку исключений, лезть в код того, что их вызвало.
Если код выплевывает исключения, которые полностью понятны без чтения этого кода - можно его завернуть в функцию и убрать с глаз долой.
Если же исключительные ситуации связаны с самой логикой метода, то размазывание этой логики по разным функциям просто нелепо.

> если у нас в try {} несколько понятных вызовов методов,

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

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

- если у нас в кетче только логинование, то трай не пишем вовсе
- если в кетче замороченная логика, то трай разумеется имеет смысл вынести в отдельный метод