> Я, кстати, писал не про данный конкретный пример, но просто когда я критикую, я стараюсть также перечислять возможные варианты.
ничего не имею против критики «на всякий случай» — пусть не расслабляются. =)
> В «древности» люди были не дураки и не плодили типы и функции просто так. В данном случае нам достаточно ввести 1 Exception, типа APIException и заворачивать в него всю информацию об ошибке, нежели плодить иерархию из типов.
Судя по тяге «достаточности» Вы в реале либо отшельник, либо скупердяй. :) На всякий случай, хочу отметить, что «достаточно» это не всегда «выгодно». В «древности» люди были невежественны, ибо имели очень смутное представление о типизации и инкапсуляции. Но в отличие от первобытных программистов, современные понимают, что типизация и инкапсуляция _выгодны_, поскольку помогают бороться с различными аномалиями кода. Если предполагается, что код не одноразовый, а будет переиспользоваться, то выгоднее каждую исключительную ситуацию описать class'ом, чем заставлять код на высших уровнях городить анализ кодов возврата. Анализ кодов возврата ненадежен и излишне многословен это уже многократно было проверенно в процессе эволюции человечества. :)
> Вы только не учли одну вещь. Статья позиционируется в ООП-парадигме. Об этом нам как бы говорят комменты автора и тэг «ооп».
Основной смысл механизма исключений — поддержка строго-иерархического разделения ответственности за идентификацию исключительной ситуации и принятие решения о дальнейших действиях — на мой взгляд, в примере показан изумительно. Комменты в коде — великолепны. О MVC речи не шло. Тег «ооп» пусть останется на совести автора.
> для передачи мета-информации об ошибке, сделать более общий тип excetpion, но с доп. объектом, в котором будет инкапсулирована эта информация и т.д.
Думаю, не надо так делать. Это антипаттерн для исключений. Наличие мета-информации связанной с ситуацией, ни как не должно влиять на тип exception.
В языках программирования, информация о том, «что есть» данные (isA), выражается при помощи типа. В механизме try-throw-catch, для представления информации об исключительной ситуации, служит объект-исключение. Тип такого объекта должен быть достаточен для идентификации этой ситуации на более высоких уровнях приложения, которые будут перехватывать исключение.
Если тип исключения будет мало информативен («СлучиласьКакаяТоФигня»), то это приведет к усложнению логики перехвата (например, анализу дополнительных данных в объекте). Поскольку решение о бросании исключения принимается в какой-то отдной точке кода, а анализ будет производиться во многих (пример, одна библиотечная функция <-> много приложений, которые ее используют), то малоинформативные исключения вынуждают делать кучу сложной работы.
Поэтому при выборе типа исключения рулит конкретизация, а излишнее обобщение как раз вредно. При необходимости, отношение обобщения между исключениями выражается при помощи наследования (в PHP все исключения это Exception).
> Если вы так делаете редирект, то ваш код крайне запутан, потому что Exception не дает нам знания о том, куда передается управление. Предполагается, что только в обработчик ошибок. Плюс к этому, это нарушение интерсфейса на самом деле. Редирект — это точно такое же View с точки зрения MVC, например
По смыслу, редирект это действие — переход из одного состояния в другое. А действия находятся за рамками структурного паттерна MVC. Для представления действий есть собственные паттерны (например, редирект можно описать как Command). Не понимаю, зачем пытаться все описать лишь тремя словами: M V C — как будто других слов нет (или «можно обойтись» это Ваше кредо?). Впрочем слогласен, что Exception здесь тоже жесть. :)
> Такое использование сильно похоже на процедурный стиль, а там можно обойтись и без Exception.
Не спорю, без исключений можно обойтись. Точно так же в процедурном стиле можно обходиться и без других языковых конструкций: switch, for, foreach, do-while,… — в пределе достаточно использовать if и goto. :) Мне кажется, что утверждение «не нужен, потому что можно обойтись», с практической точки зрения, лишено смысла.
Замечу, что Exceptions в стиле try-throw-catch это чисто процедурный механизм. Просто он получил популярность в ООП-языках, поэтому часто ассоциируется с этим подходом. Но это не так. Как мы видим в примере из статьи, данная конструкция может прекрасно работать безо всякого ООП даже в «лапше».
ничего не имею против критики «на всякий случай» — пусть не расслабляются. =)
> В «древности» люди были не дураки и не плодили типы и функции просто так. В данном случае нам достаточно ввести 1 Exception, типа APIException и заворачивать в него всю информацию об ошибке, нежели плодить иерархию из типов.
Судя по тяге «достаточности» Вы в реале либо отшельник, либо скупердяй. :) На всякий случай, хочу отметить, что «достаточно» это не всегда «выгодно». В «древности» люди были невежественны, ибо имели очень смутное представление о типизации и инкапсуляции. Но в отличие от первобытных программистов, современные понимают, что типизация и инкапсуляция _выгодны_, поскольку помогают бороться с различными аномалиями кода. Если предполагается, что код не одноразовый, а будет переиспользоваться, то выгоднее каждую исключительную ситуацию описать class'ом, чем заставлять код на высших уровнях городить анализ кодов возврата. Анализ кодов возврата ненадежен и излишне многословен это уже многократно было проверенно в процессе эволюции человечества. :)
Основной смысл механизма исключений — поддержка строго-иерархического разделения ответственности за идентификацию исключительной ситуации и принятие решения о дальнейших действиях — на мой взгляд, в примере показан изумительно. Комменты в коде — великолепны. О MVC речи не шло. Тег «ооп» пусть останется на совести автора.
Думаю, не надо так делать. Это антипаттерн для исключений. Наличие мета-информации связанной с ситуацией, ни как не должно влиять на тип exception.
В языках программирования, информация о том, «что есть» данные (isA), выражается при помощи типа. В механизме try-throw-catch, для представления информации об исключительной ситуации, служит объект-исключение. Тип такого объекта должен быть достаточен для идентификации этой ситуации на более высоких уровнях приложения, которые будут перехватывать исключение.
Если тип исключения будет мало информативен («СлучиласьКакаяТоФигня»), то это приведет к усложнению логики перехвата (например, анализу дополнительных данных в объекте). Поскольку решение о бросании исключения принимается в какой-то отдной точке кода, а анализ будет производиться во многих (пример, одна библиотечная функция <-> много приложений, которые ее используют), то малоинформативные исключения вынуждают делать кучу сложной работы.
Поэтому при выборе типа исключения рулит конкретизация, а излишнее обобщение как раз вредно. При необходимости, отношение обобщения между исключениями выражается при помощи наследования (в PHP все исключения это Exception).
По смыслу, редирект это действие — переход из одного состояния в другое. А действия находятся за рамками структурного паттерна MVC. Для представления действий есть собственные паттерны (например, редирект можно описать как Command). Не понимаю, зачем пытаться все описать лишь тремя словами: M V C — как будто других слов нет (или «можно обойтись» это Ваше кредо?). Впрочем слогласен, что Exception здесь тоже жесть. :)
Не спорю, без исключений можно обойтись. Точно так же в процедурном стиле можно обходиться и без других языковых конструкций: switch, for, foreach, do-while,… — в пределе достаточно использовать if и goto. :) Мне кажется, что утверждение «не нужен, потому что можно обойтись», с практической точки зрения, лишено смысла.
Замечу, что Exceptions в стиле try-throw-catch это чисто процедурный механизм. Просто он получил популярность в ООП-языках, поэтому часто ассоциируется с этим подходом. Но это не так. Как мы видим в примере из статьи, данная конструкция может прекрасно работать безо всякого ООП даже в «лапше».