В чем разница вызова exception

[`p r o x y]

В рамках Zend, возможно, такой вариант уместней.
Так как в проекте может быть свой обработчик set_error_handler.

 

[Фанат]

Ну тогда это ещё один гвоздь к крышку гроба монстрофреймворков

 

[fixxxer]

Да просто нефиг. Пишется в документации "переопределил руками set_error_handler или exception handler - сам дурак", и все.
Иначе можно точно так же сказать "в проекте может быть своя работа ручками с $_GET и $_POST, и с базой своя работа ручками через mysql_query". Идите в жопу, фреймворк на то и фреймворк что навязывает свои решения. В хорошем фреймворке обязаны быть архитектурные решения, позволяющие обойтись без ручной работы на низком уровне.

 

[A1x]

A1x
я предлагаю делать всё то же самое, но на глобальном уровне

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

дичь - писать эту колбасу перед каждой функцией

так другого способа нет к сожалению, если не делать предположений что это уже сделано на глобальном уровне

 

[fixxxer]

Опять же идите в жопу, я вот щас возьму из zend_mail класс для работы с smtp и буду ходить жаловаться что он сам по себе не работает, и что кто тут будет дурак?
Для класса фреймворка совершенно логично подразумевать что он работает в подготовленной среде.
Если хочется гибкости - выносим класс Zend_Environment с методами setup() и restore(), хочешь строить все из кусочков зенда - пожалуйста, только вот Environment захвати. Всякие новомодные композеры прекрасно решат проблему зависимостей, если лень прочитать ман.

 

[A1x]

Для класса фреймворка совершенно логично подразумевать что он работает в подготовленной среде.

ну как раз всегда считалось преимуществом ZF его "слабосвязанность" (или как там) - что я могу взять тот же Zend_Маіl
и использовать где угодно, без необходимости тащить весь фреймворк