Почему «бежать и бросать» считается антипаттерном? [закрыто]

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

Почему регистрация исключения с последующим его повторным генерированием (конечно, с сохранением исходной трассировки стека) - плохая идея, если вы не можете справиться с этим иначе?

Я предполагаю, что ответ в основном состоит в том, почему вы ловите это, если не можете с этим справиться? Почему бы не позволить тому, кто может с этим справиться (или кому не остается другого выбора, кроме как справиться с этим), записать его, если они считают, что это достойно ведения журнала?

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

Также некоторые могут возразить, что, поскольку выброс и перехват исключений являются относительно дорогостоящими операциями, весь этот перехват и повторное генерирование не помогает вашей производительности во время выполнения. Это также не помогает вашему коду с точки зрения краткости или удобства обслуживания.

Log-and-throw - хороший шаблон, если у объекта, улавливающего и повторно генерирующего исключение, есть основания полагать, что оно содержит информацию, которая не будет регистрироваться дальше по стеку вызовов - по крайней мере, не самым желаемым образом. Это может произойти по нескольким причинам:

1. Исключение может быть перехвачено и повторно создано на границе уровня приложения и может содержать привилегированную информацию. Было бы плохо, если бы уровень базы данных разрешил исключение, например, «Попытка добавить повторяющийся ключ 'fnord' в поле 'users'», чтобы достичь внешнего уровня приложения (который, в свою очередь, мог бы открыть его пользователю), но это может быть полезно для внутренних частей базы данных, чтобы генерировать такое исключение, и для интерфейса приложения, чтобы поймать его, безопасно зарегистрировать и повторно генерировать несколько менее описательное исключение.
2. Исключением может быть то, что внешний уровень, вероятно, ожидает обрабатывать без регистрации, но внутренний уровень может знать что-то, чего не знает внешний уровень, что предполагает, что ведение журнала может быть полезно. В качестве грубого примера средний уровень приложения может быть запрограммирован на попытку подключения к одному серверу, а если это не сработает, попробовать другой. Заполнение журнала приложения сообщениями «сбой подключения», когда сервер отключен для обслуживания, может быть бесполезным, тем более, что с точки зрения приложения все работало нормально. Может быть полезно перенаправить информацию о сбое подключения к ресурсу ведения журнала, связанному с серверами, который затем может фильтровать журналы, чтобы создавать отчет о том, когда сервер выходил из строя и когда он выходил из строя, в отличие от журнала каждой попытки подключения. .

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

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

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

Журнал ИМО и бросок - явное нарушение принципа наименьшего неожиданности.

Если исключение обрабатывается должным образом дальше по стеку вызовов, запись в журнал ошибок может вообще не иметь смысла. И тогда сбивает с толку запись в журнале ошибок.