Хорошая ли практика создавать свои классы Exception для отлавливания разных ошибок?

Question

[Dreaded]

Я только недавно изучил механизм Exception'ов и сейчас их осваиваю. Вот пара вопросов по поводу их применения:

Можно ли создавать свои пустые классы Exception'ов наследуемые от класса Exception только лишь для того что бы было отдельное имя исключения? Например: я работаю с файлами, и если файл не удалось загрузить файл - я бросаю исключение

throw new FileException('Не удалось загрузить файл')

Сам класс `FileException ничего не содержит:

class FileException extends \Exception
    {
        //empty!
    }

И второй вопрос, который вытекает из первого. Делаю я это для того что бы отловить различные ошибки. Например при добавлении сообщения на сайте, у меня может возникнуть разные исключения, например: Не корректное сообщение, Не удалось загрузить файл, ошибка PDO. То есть в контроллере это будет выглядеть так:

public function actionMethod()
    {
        try {
            //some code;
        } catch (FileException $e) {
            echo 'С файлами что то пошло не так:' . $e->getMessage();
        } catch (MessageException $e) {
            echo 'С сообщением что то пошло не так:' . $e->getMessage();
        } catch (PDOException $e) {
            echo 'С БД что то пошло не так:' . $e->getMessage();
        } catch (Exception $e) {
            echo 'Что то совсем пошло не так :(';
        }
    }

Можно ли так делать? Это нормально что в контроллере столько много catch'eй? На сколько это хорошая практика? Или я не правильно понял механизм работы исключений?

update: И как быть, если у меня возникает несколько исключений, и я хочу выдать пользователю информацию о всех возникших сразу?

Comments

[Дмитрий Евграфович]

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

Answer 1

[galliard]

Практика хорошая. Именно так и стоит делать. В идеале у каждой ошибки должен быть свой уникальный эксепшн. Например, от FileException можно наследовать например NotFoundFileException и AccessFileException. При этом тело классов в большинстве случаев будет пустым.

А вот то, что ты пытаешься поймать все возможные эксапшны в контроллере - это совсем не хорошо. По хорошему нужен отдельный эксепшн хендлер для этого.

Comments

[Александр Дуплий]

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

[galliard]

Александр Дуплий, конечно степень детализации уже определит каждый конкретный программист, но все же перекос в сторону "свое исключение на каждый чих" предпочтительнее, чем "везде одни и те же исключения, в основном только встроенные или от фреймворка".

Ну и по поводу контроллера, конечно часть исключений там поймать можно, но вот FileException, PDOException и уж тем более Exception к таковым явно не относятся.

[WhoMe]

> В идеале у каждой ошибки должен быть свой уникальный эксепшн.
Зачем? Это можно оправдать, если вы пишете какую-то опенсорс библиотеку и вы не можете предсказать как она будет использоваться. И то при наличии продуманной иерархии ошибок, а не просто каждому throw new по своему классу.

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

Зачем вам AccessFileException?
Если вы после этой ошибки программно выставляете нужные права - то ок.
Если вы просто выводите сообщение - то зачем?

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

[galliard]

WhoMe, а затем, что сегодня это твой проект, завтра твой и Васин, а послезавтра Васин и Димин, а послепослезавтра Димин и Ванин. И от того, что ты когда-то знал (но уже давно забыл) как там все раньше работало Диме и Ване не легче.

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

Зачем вам AccessFileException?
Если вы после этой ошибки программно выставляете нужные права - то ок.
Если вы просто выводите сообщение - то зачем?

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

[WhoMe]

твой проект

Под "ваш проект" я имел ввиду что вы (участники проекта, текущие и будущие), внутри вашей компании, являетесь единственными пользователями этой кодовой базы.
Это значит что требования к кодовой базе исходят только от вас и вы же их реализуете.

Может сейчас тебе кажется, что потом они понадобятся.
Поверь, в 8 из 10 случаев не понадобятся (цифра с потолка).
Вместо того чтобы выявлять требования, ты тратишь время на их выдумывание, и хорошо если угадаешь.

Проще всего поддерживать код которого нет.

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

Согласен (но не основной). Именно поэтому я предлагаю создавать Exception-ы под реальные требования проекта, а не под себя любимого.

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

Всмысле?
Стек трейс никто не отменял. Мы ведь про php говорим, да?
Ты же сообщение об ошибке то туда положишь? throw new FileException("Нет доступа к файлу");
У тебя же есть текстовый редактор который найдет все "new FileException", да?
Че тут аццкого?

[galliard]

Может сейчас тебе кажется, что потом они понадобятся.
Поверь, в 8 из 10 случаев не понадобятся (цифра с потолка).
Вместо того чтобы выявлять требования, ты тратишь время на их выдумывание, и хорошо если угадаешь.

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

Согласен (но не основной). Именно поэтому я предлагаю создавать Exception-ы под реальные требования проекта, а не под себя любимого.

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

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

Стек трейс никто не отменял. Мы ведь про php говорим, да?
Ты же сообщение об ошибке то туда положишь? throw new FileException("Нет доступа к файлу");
У тебя же есть текстовый редактор который найдет все "new FileException", да?
Че тут аццкого?

Стектрейсом ты найдешь один эксепшн, у тебя их 1000. Из них только некоторые связана с доступом, их может 50, может 200, а может 500 конкретную цифру никто не знает, поэтому проверить придется всю 1000. Кто-то напишет "Нет доступа к файлу", кто-то "Файл недоступен", кто-то "Файл не читается", кто-то ещё на английском напишет. Кто-то вообще напишет что-то невнятное, и чтобы понять, что произошло, придется вчитываться в окружающий код, или ещё хуже - запускать его. После 50 таких исправлений ты устанешь заниматься муторной однотипной фигней, у тебя начнет в глазах рябить от них, ты начнешь путаться и делать ошибки. И это при том, что 95% всей работы ещё не сделано.

Answer 2

[WhoMe]

UPD:
> Это нормально что в контроллере столько много catch'eй?
Не то чтобы нет, но "попахивает".
> как быть, если у меня возникает несколько исключений, и я хочу выдать пользователю информацию о всех возникших сразу

У вас смешана валидация входных параметров с возникновением нештатных ситуаций.
Exception стоит кидать если метод не может вернуть осмысленный результат.
Ошибки валидации ("сообщение слишком длинное", "файл не того расширения") можно собирать, к примеру, в массив. Как валидировать входные данные выходит за рамки этого вопроса.
------
> Можно ли так делать?
Попробуйте использовать правило 5 почему (ну или "зачем") чтобы попытаться добраться до сути.

- Я даю отдельные имена исключениям.
- Зачем?
- Для того что бы отловить различные ошибки.
- Зачем отлавливать различные типы ошибок?
- Чтобы показывать разные сообщения.
- Зачем показывать разные сообщения?
- Чтобы пользователь мог отреагировать определенным образом на конкретный тип ошибки
(решить что ему делать в случае конкретного исключения).

Давайте посмотрим что человек (пользователь) на вашем сайте (системе) может сделать в случае ошибки:
1. Не корректное сообщение.
Привести его к корректному (сделать его короче, как-то отформатировать и т.п.)

2. Не удалось загрузить файл.
Если файл слишком большой - можно попробовать загрузить файл поменьше.
Если это внутренняя ошибка (например: закончилось место на диске на сервере, нет прав на запись и т.п) - то ничего, здесь уже требуется вмешательство тех кто обслуживает систему.

3. Ошибка PDO.
Ничего, это внутренняя ошибка.

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

Я использую 2 типа исключений на уровне web-слоя: внешние и внутренние.
Внешние - если пользователь может повлиять на них (страница не найдена, файл слишком большой, нет доступа и т.п.).
В них сообщение показывается пользователю как есть. Подноготная (пути к файлам, пароли, названия БД и т.п) в такие ошибки не вкладывается.

Внутренние - пользователь не может влиять (ошибка подключения к БД, SQL syntax error и т.п).
Пользователю показывается только код ошибки. В такие ошибки также вкладываю техническую информацию.

Ты (как программист) также можешь быть пользователем какой-то системы (к примеру, библиотеки).
Например, библиотеки для работы с БД.
Предположим ты импортируешь csv-файл в базу, заполняешь числовую колонку и вместо числа у тебя попадается текст.
Запрос падает с ошибкой и тебе не плохо бы отличать её от ошибки синтаксиса.
Если попался текст вместо числа - то можно просто пропустить строку.
Если ошибка синтаксиса - то у ошибка в коде и продолжать импорт нет смысла.

Подытожу:

> Можно ли создавать свои пустые классы Exception'ов наследуемые от класса Exception только лишь для того что бы было отдельное имя исключения?

Можно.

Сколько делать отдельных исключений?
Зависит от того как их будет обрабатывать пользователь.
Если твой контроллер(модель, подсистема) кидает множество разных ошибок и все они обрабатываются одинаково - то стоит призадуматься.

Comments

[galliard]

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

[WhoMe]

galliard, Наверное ответ слишком сумбурный получился.
Для меня программист тоже "пользователь". Да, именно он решает, как их обрабатывать и обрабатывать ли вообще.
Я с этим не спорю. Понятное дело что пользователь сайта не получает ошибок (в терминах ЯП) напрямую.
Их получает некий слой, который затем формирует страницу ошибки. И да, программист пишет этот слой.
Там где я писал про "2 типа исключений" я имел ввиду имено этот слой.

Видимо я не правильно понял вопрос.
Наверное автора больше беспокоит количество catch блоков и почему их получилось так много.
Я же отвечал на вопрос можно ли "создавать свои классы Exception для отлавливания разных ошибок?" и сколько их нужно.

Спасибо за комметарий, получилось чуть лучше понять вопрос.

[Златослав Десятников]

WhoMe, ага, также не учли, что разные типы эксепшнов позволяют упростить работу с unit-тестами

Answer 3

[Дмитрий]

Во фреймворках так и делают. Я в своей практике использую несколько исключений. Так что это нормально. Почитайте еще про интерфейс \Throwable, который появился в PHP 7

Answer 4

[Евгений Педя]

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