Вот и я о том же.
При такой модели работы, если нужно передать в обработчик ошибок дополнительную информацию (кроме типа исключения). Тут и пригодится пункт 5 — исключения это объект сам по себе и его можно расширять. И не нужно изобретать дополнительные грабли.
При таком подходе я бы вам не советовал пользоваться исключениями.
Пункту 4 так же справедлив, если возникает не предвиденная ранее ошибка (которую не предусмотрел разработчик и не увидел тестеровщик) в продакшине. В вашем коде никогда не находили баги в продакшине? Так во первых можно будет свое временно узнать об ошибке, будет откуда начать поиск в виде trace исключения в логе.
Правило 1 — если где-то в коде бросается системное исключение (Exception), то и ловить его придется так
try{
//...
} catch(myException $e) {
//...
} catch(Exception $e) {
//здесь вы можете поймать все, что не поймали раньше
}
получается, что вся сложная иерархия исключений идет лесом, так как все исключения скопом поймает все, которые не были указаны в списке выше.
Пункт 4 — глобальный обработчик нужен для того, чтобы обрабатывать все не пойманные ранее исключения и обработать их хоть как-то — вывести сколь нибудь понятное сообщение пользователю, залогировать их или отослать письмо разработчику.
Что вы скажите про такой вариант pastebin.com/6Z9irna3? Логика перевода вынесена из класса исключения в метод для view; интерфейс сведен к минимуму, так что повторения кода не значительны. Сам Exception служит контейнером для переноса сообщения и переменных.
Рассмотрим пример с игрой. Есть метод для создания игрового предмета из имеющихся материалов. Этот метод делает разные проверки, наличие предметов, маны, свободного места в рюкзаке итп. При неудачной попытке создания предмета, нужно показать пользователю сообщение следующего вида «У вас недостаточно маны(13) нужно 15» итп. Это сообщение нужно выводить на разных языках в зависимости от настроек пользователя. Соответственно этот метод может возвращать true в случае успеха или объект(ассоциативный массив) с шаблоном текста ошибки «У вас недостаточно маны(%d) нужно %d» и набор из двух переменных. Для того, чтобы показать, это сообщение нужно будет сначала в таблице переводов, найти шаблон ошибки в нужном языке, а потом уже подставить переменные. Фактически этот метод с кастомным механизмом ошибок. Можно не плодить такие кастомные механизмы, а использовать Exception, который в себе будет содержать всю необходимую информацию, как содержит ее в себе объект возвращаемый методом.
Если, подвести итог, то я не настаиваю на таком подходе, в конце концов, этот выбор каждый разработчик делает для себя сам.
Документ, я не читал потому что, ваш второй комментарий я увидел позже, после написания своего. А причина такая, что не нужно пытаться натянуть принципы для С++ на PHP. C++ это низкоуровневый язык, вы же не будете писать на нем повседневные интернет приложения. (Хотя, можно написать отдельные высоконагруженые куски).
Следуя тому же документу, там предлагается 5 за и 5 против, и из 5 против к PHP подходит один два. И выбор они делают против исключений, только потому, что сложность работы с исключеними в С++ гораздо больше позитивных моментов. В PHP не так сложно работать с исключениями.
С другой стороны, насколько я понимаю, вы не против исключений, так как говорите:
> но я не предлагаю работать без исключений. я предлагаю считать исключительной ситуацией падение БД
Так что, я не понимаю, зачем вы опубликовали ссылку на документ в котором предлагают отказаться от исключений совсем.
Этот exception это translateException. Задача — передать сообщение с ошибкой (которое можно перевести и в нем есть вариативные части) из кода к месту, где ошибка выводится пользователю.
Хорошо, этот exception генерируется только в контролерах или только в одном модуле — проблема с наследованием решена. Или сам метод перевода убрали во внешнюю часть — обработчик на уровне view. Но мне до него все равно нужно донести шаблон текста ошибки и переменные. Как вы предлагаете решить эту задачу.
Мы приближаемся.
Ок, метод возвращает true/false. Т.е фактически мы создали новую схему обработки ошибок. Если все нормально возвращаем true, если все плохо возвращаем false. И того у нас два варианта один позитивный один негативный. Теперь представим, что логика немного сложнее, чем два варианта — 1 позитивный и 3 негативных. Начинаем, изобретать велосипед под названием кастомный механизм работы с ошибками. А смысл?
Вопрос реализации решается легко: полиморфизм решаем интерфейсами (в интерфейс переделываем translateException — iTranslateException), дублирование кода минимизируем вынесением кода в статический метод, а потом будем его вызывать из не статических функций класса. Проблемы наследования надо решать по месту. Этот Exception может генерироваться на уровне контролеров, а не модулей, тогда проблема совсем не актуальна.
Вы не ответили на вопрос как мне передать такое сообщение. Вас спросили:«Доктор, у меня болит голова когда я лежу на левом боку. Что делать?». Вы ответили:«Не лежите на левом боку».
Я не увидел ни строчки про лок таблицы с балансом, т.е. возможна ситуация когда два инстанса кода сначала проверят баланс (он достаточный), после оба так же удачно снимут с него деньги, когда их фактичеки не хватает. Может этот пример с одним пользователем кажется не актуальным, а если речь идет про счет в банке у которого много пользователей или кроме проверки баланса еще идет запрос (растянутый во времени) на другой сервис…
Ну почему в С/С++ не используют исключения это понятно — экономят память. Потому как любое исключение по пути собирает на себе весь стек вызовов. Но С/С++ актуален для low-lewel вещей. Не надо путать теплое с мягким
При такой модели работы, если нужно передать в обработчик ошибок дополнительную информацию (кроме типа исключения). Тут и пригодится пункт 5 — исключения это объект сам по себе и его можно расширять. И не нужно изобретать дополнительные грабли.
Пункту 4 так же справедлив, если возникает не предвиденная ранее ошибка (которую не предусмотрел разработчик и не увидел тестеровщик) в продакшине. В вашем коде никогда не находили баги в продакшине? Так во первых можно будет свое временно узнать об ошибке, будет откуда начать поиск в виде trace исключения в логе.
получается, что вся сложная иерархия исключений идет лесом, так как все исключения скопом поймает все, которые не были указаны в списке выше.
Пункт 4 — глобальный обработчик нужен для того, чтобы обрабатывать все не пойманные ранее исключения и обработать их хоть как-то — вывести сколь нибудь понятное сообщение пользователю, залогировать их или отослать письмо разработчику.
За ссылку спасибо, почитаю.
Если, подвести итог, то я не настаиваю на таком подходе, в конце концов, этот выбор каждый разработчик делает для себя сам.
Следуя тому же документу, там предлагается 5 за и 5 против, и из 5 против к PHP подходит один два. И выбор они делают против исключений, только потому, что сложность работы с исключеними в С++ гораздо больше позитивных моментов. В PHP не так сложно работать с исключениями.
С другой стороны, насколько я понимаю, вы не против исключений, так как говорите:
> но я не предлагаю работать без исключений. я предлагаю считать исключительной ситуацией падение БД
Так что, я не понимаю, зачем вы опубликовали ссылку на документ в котором предлагают отказаться от исключений совсем.
в смысле на самом верхнем уровне приложения — например в бутстрапе
Ок, метод возвращает true/false. Т.е фактически мы создали новую схему обработки ошибок. Если все нормально возвращаем true, если все плохо возвращаем false. И того у нас два варианта один позитивный один негативный. Теперь представим, что логика немного сложнее, чем два варианта — 1 позитивный и 3 негативных. Начинаем, изобретать велосипед под названием кастомный механизм работы с ошибками. А смысл?
Вы не ответили на вопрос как мне передать такое сообщение. Вас спросили:«Доктор, у меня болит голова когда я лежу на левом боку. Что делать?». Вы ответили:«Не лежите на левом боку».