Throwing an Exception Without Proper Context Is a Bad Habit

The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:

Я продолжаю совершать одну и ту же ошибку снова и снова. Поэтому пришло время остановиться и создать правило, чтобы предотвратить ее возникновение впредь. Ошибка не фатальна, но очень раздражает. Когда я смотрю на журналы производства, часто вижу что-то вроде "Файл не существует", и задаю себе вопрос: Какой файл? Где он должен существовать? Что сервер пытался сделать с ним? Что происходило секунду до сбоя? В журнале нет ответа, и это полностью моя вина. Я либо 1) не перебрасываю исключение, либо 2) перебрасываю исключение без указания контекста. Оба варианта неправильны.

Вот как может выглядеть код:

Также может выглядеть так:

Оба примера демонстрируют неадекватный стиль обработки ситуаций, связанных с исключениями и их отчетностью. Что здесь не так? Сообщения об исключениях недостаточно подробны. Они просто не содержат никакой информации о месте, откуда они произошли.

Вот как они должны выглядеть вместо этого:

И второй пример должен выглядеть так:

Видите разницу? Это может выглядеть как избыточный код, но на самом деле не является таковым. Конечно, когда я все это пишу, мне не так важны журналы и исключения. Я на самом деле не ожидаю, что этот файл будет отсутствовать.

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

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

Выбрасывание исключения - это буквально эскалация проблемы на более высокий уровень управления. Представьте, что мой начальник просит меня установить новый сервер. Я возвращаюсь к нему через несколько часов и говорю: “Я не справился, извините.” Это бы звучало странно. Он бы попросил больше деталей. Почему я не справился? Что именно пошло не так? Можно ли сделать это по-другому? И так далее.

Такой код буквально является проявлением неуважения к клиенту:

Мне нужно быть более разговорчивым и давать больше деталей.

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

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

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

Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-22 at 09:52

sixnines availability badge   GitHub stars