Здравствуйте, Буравчик, Вы писали:
Б>Когда стоить заводить собственные классы исключений (custom excceptions)? Б>Как вы делаете в своем коде?
У меня есть класс UserException, сообщение которого показывается юзеру (остальные исключения журналируются и юзеру показывается только код ошибки). Это UserException бросается в т.ч. при ошибках валидации параметров запроса. И больше вроде бы ничего.
Здравствуйте, Буравчик, Вы писали:
Б>Здравствуйте, Rinbe, Вы писали:
R>>Делаем для своих велосипедов библиотек.
Б>А подробнее? Б>В каких случаях делаете? Б>Сколько их — "на каждый чих" или несколько общих? Б>и т.п.
Для валидации использую стандартные, а для действий недопустимых для данного состояния объекта-свои.
Здравствуйте, Буравчик, Вы писали:
Б>Здравствуйте, Rinbe, Вы писали:
R>>Делаем для своих велосипедов библиотек.
Б>А подробнее? Б>В каких случаях делаете? Б>Сколько их — "на каждый чих" или несколько общих? Б>и т.п.
Отталкиваюсь от сценариев обработки.
Тривиальный случай — если вообще не обрабатывать, как упало, так и ладно. Достаточно одного класса.
Шаг индукции:
а) требуется обработка чего-то более специального, чем стандартные исключения, чего не кидает фреймворк/либы.
б) требуется обработка чего-то более общего, чем стандартные исключения. например, ошибку формата/конец потока/файл не найден следует обобщить и интерпретировать как "невозможность прочитать конфигурацию". Тогда клиентский код сможет отреагировать и вспомнить предыдущую, выдумать конфигурацию по умолчанию или еще что-то, не обращая внимания на источник.
Итого, как только необходимо научиться отличать какую-то новую ситуацию от других, не занимаясь парсингом текста сообщения и разборов кодов ошибок.
Здравствуйте, Буравчик, Вы писали:
Б>Когда стоить заводить собственные классы исключений (custom exceptions)?
Когда вы ожидаете от клиентского кода, что он будет эти исключения перехватывать. При условии, что стандартные исключения вам не подходят.
Б>Как вы делаете в своем коде?
Стандартные рекомендации, вот сокращённый вариант. Подробности можно подглядеть в Framework Design Guidelines book.
Здравствуйте, Буравчик, Вы писали:
Б>Когда стоить заводить собственные классы исключений (custom exceptions)? Б>Как вы делаете в своем коде?
Везде все может быть сильно по разному. Зависит от приложения. UserException делали в основном для всяких либ/фреймворков, но если можно без них, лучше без них.
Здравствуйте, dimgel, мы писали:
D>У меня есть класс UserException, сообщение которого показывается юзеру (остальные исключения журналируются и юзеру показывается только код ошибки). Это UserException бросается в т.ч. при ошибках валидации параметров запроса. И больше вроде бы ничего.
Во, ещё чё в архивах нашлось: класс EBreak. Такой дальний break через годы, через расстоянья вложенные циклы и границы методов. Где ловлю — молча глотаю (throw и catch по нему строго согласованы, естественно).
