[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Exception VS trigger_error при дебаггинге
Страницы: 1, 2, 3, 4
twin
Недавно один горячий парень хотел оторвать мне руки за то, что я пользуюсь trigger_error() вместо trow new Exception().

Вот я тут набросал соображения по этому поводу. Сразу выкладываю на суд Линча, что бы потом меня опять не обвинили в нубстве.

У кого какие есть соображения? Только не в плане "все тру программисты давно уже...", а в режиме нормального обсуждения.

UPD. Экшен в конце статьи, кто не дочитает, ничего не пишите.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
Oyeme
Когда у Вас Вложенность exception более сотни/тысяч файлов нужно работать не посредственно с exception,тем самым отлавливая разные види ошибок на разных уровнях вложенности и обрабатывая их по разному.Поэтому у вас есть контроль всего flow.

Используя trigger_error() в Вашем случаи программа останавливается и продолжение не востановимо. wink.gif
wink.gif
forza
Мое скромное мнение:
Вообще exceptions нужно использовать там где они действительно нужны, а не сувать где попало. Например транзакция в базе данных. Как вы отловите исключение и сделаете rollback?

$transaction = $db -> beginTransaction();
try {
...
} catch(Exception $e) {
$transaction -> rollback();
}


Еще пример: использование 3rd party API, если вдруг обрывается запрос к другому серверу (возвращается соответсвующий статус), и вам нужно повторить запрос.


try {
// Request
} catch(ThirdPartyException $e) {
// Network problem
if(1 == $e -> getCode())
do another request.
}


А вообще, хочу обратить ваше внимание на заключение. У вас написано 5 плюсов за использование trigger_error, и не одного за исползьование throw new, хотя 2 моих примера заслуживают попадания в них.
В нашем мире нету ничего совершенного.

_____________
Заработок для веб-разработчиков: CodeCanyon
Мое Портфолио
twin
Цитата (Oyeme @ 31.07.2013 - 14:53)
Когда у Вас Вложенность exception более сотни/тысяч файлов нужно работать не посредственно с exception,тем самым отлавливая разные види ошибок на разных уровнях вложенности и обрабатывая их по разному.Поэтому у вас есть контроль всего flow.

Используя trigger_error() в Вашем случаи программа останавливается и продолжение не востановимо. wink.gif
wink.gif

Три раза прочитал, ничего не понял... Можно подробнее?

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
twin
Цитата (forza @ 31.07.2013 - 14:58)
А вообще, хочу обратить ваше внимание на заключение. У вас написано 5 плюсов за использование trigger_error, и не одного за исползьование throw new, хотя 2 моих примера заслуживают попадания в них.
В нашем мире нету ничего совершенного.

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

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
T1grOK
Цитата (forza @ 31.07.2013 - 14:58)
Например транзакция в базе данных. Как вы отловите исключение и сделаете rollback?

Не поверите, но при правильной архитектуре это работает. Часто использую такую конструкцию в Kohana, где требуются транзакции.

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
twin
Ничего опять я не понимаю. Ну разве одно другому мешает? Вот я написал функцию хэширования паролей. Это функция, не часть системы. Там есть такие строчки:
    function cryptPassword($password, $logic = 3, $hash = '', $round  = 10)
{
if(CRYPT_MD5 != 1)
{
trigger_error(__FUNCTION__ .'(). '
.'The system does not support md5 algorithm',
E_USER_WARNING);
return false;
}
Я могу применять её где угодно, где есть исключения и где нет.
Разве нельзя отработать её эксепшеном, если на то пошло?

try
{
if(!cryptPassword('password'))
throw new Exception('Кирдык');
}.....


Эта схема совершенно не отменяет другие исключения. Но моя функция выдаст варнинг (пользовательский) и вообще без них. А вот если бы я стал мудрить с исключениями в функции, она перестала бы быть самодостаточной.

Цитата
Хотя неплохо бы, конечно, сразу обучаться правильным вещам.
А как правильно на ваш взгляд в двух словах?

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
twin
Бог с ней, с функцией. Поставлю обратно exit() специально убрал для этих эксепшенов, зря. Не в ней дело.

Дело больше в исключительных ситуациях при дебаггинге. Ведь если пользоваться ексепшенами как таковыми, любая ошибка будет отрабатывать по статусу fatal error.

Тоесть останавливать скрипт при любом нотисе, это правильный подход при отладке? Или это актуально только для "больших систем"?

Я просто силюсь представить такую систему и не могу. У меня на работе проект, в нем файлов на порядок больше, чем в Yii и нет ни одного исключения. Четвертый год работает, через него проходят миллионы, ни одного серьёзного сбоя не было пока. Просто один раз отдебажен и прет. Так я с ума бы сошел, если бы мне на каждый чих выкидыалось по очереди исключение как в Yii

Кстати, а в нем можно отключить дебаг? Я не про YII_DEBUG, а вообще. Что бы на экран не лезло это:
Цитата
Internal Server Error
Undefined variable: b
An internal error occurred while the Web server was processing your request. Please contact the webmaster to report this problem.

Thank you.



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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
twin
Цитата
> Тоесть останавливать скрипт при любом нотисе, это правильный подход при отладке?
Исключительно правильный. При отладке, конечно. Варнинги - хороший инструмент предотвращающий внезапные трудноуловимые проблемы. Ошиблись, там, в названии ключа массива, или еще что-то подобное.


Я имел ввиду не это. Я имел ввиду, что без ексепшенов я получаю на экран все нотисы и варнинги сразу. А не по очереди. Вот Yii реагирует на них по одному.

Вот это я имел ввиду:

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
twin
Цитата (MiksIr @ 31.07.2013 - 17:15)
Ну да, у Yii так, у кого-то иначе. Может и удобнее, но обычно нотисы не ходят пачками, если разрабатывать и тестировать сразу, так что большой разницы не вижу.


Всяко бывает. И нотисы и варнинги. Особенно в циклах.

Цитата
Только это никакого отношения к исключениям не имеет.

Так вот именно. О чем я и говорю давно. Это не совсем исключения, это схема дебаггинга. Просто если дебаг строить на основе исключений, вот такая бяка и вылазит. Особенно с логами бяда. Что я и попытался обойти.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.