Меню
Что нового?

Исключения или trigger_error?

itprog

itprog

Cruftsman
Духовность™
а по-моему это у автора проброс %)

Ошибки они и есть ошибки, некоторые можно исправить, другие игнорировать, либо нельзя ни то и ни другое. А исключения это уже инструмент, который можно применять для управления ошибками и получить некоторые преимущества: распространение вверх по стеку (или как автор, "проброс") и группировка ошибок.

PS: "Не надо использовать исключения для улучшения быстродействия или сообщения об ошибках.". Почему автор начал про быстродействие в заключении?
 
  • Like
Реакции: atv

atv

Новичок
ошибка — не поправимая ситуация;
Нажмите для раскрытия...
Не бывает не поправимых ситуаций, всё зависит от логики приложения. Вон, Котеров, даже фатал эррор отлавливал, раз того требует логика приложения. Но на этапе низкоуровневой разработки кода нельзя сказать, будет ли обрабатываться та или иная ошибка, поэтому лучше взять за правило ВСЕГДА сообщать об ошибке выбрасывая исключение, а уже в КОНКРЕТНОМ приложении будет приниматься решение что с этим исключением делать, то-ли обработать незаметно для пользователя, то-ли красиво завершить приложение с извинениями для пользователя.

Если у Вас нет каскада
Нажмите для раскрытия...
Это когда же нет, каскада? Разве что в "Hello World". В любом, мало-мальски функциональном приложении глубина вызова функций как минимум три-четыре уровня. И что, на каждом уровне проверять возврат функции? Добро пожаловать в ад.
 
  • Like
Реакции: Gas

Вурдалак

Продвинутый новичок
PHP: 
function myErrorHandler(...)
{
    // show internal error
}
PHP: 
try {
    $application->run();
} catch(Exception $e) {
    // show internal error
}
Т.е. то, что там автор называет ошибками — ничто иное как исключение, которое ловится где-то в index.php (грубое сравнение). По-моему, автор откровенно мудак.
 
Духовность™

Духовность™

Продвинутый новичок
ещё раз - не на все ошибки нужно делать исключение, т.е. не нужно прерывать рабочий ход проги.
 

atv

Новичок
пример выше - мой код
Нажмите для раскрытия...
PHP: 
if (!in_array($action, array('set', 'get')))
            {
                trigger_error('Указан некорректный action <b>' .
                              $action .
                              '</b> в контексте вызова метода <b>' .
                              __METHOD__ . '</b>', E_USER_WARNING);

                return null;
            }
Т.е. я, как пользователь твоего кода, должен буду проверять при каждом вызове твоего метода, а не вернул ли он мне null, чтобы понять, отработал он корректно или нет. Т.е. что-то типа того
PHP: 
if (!$obj->getMethodNameByKeyWithPrefix('Vasya')) {
    AAAAAA!!! HELP ME!!!
}
Но, даже если я и буду проверять результат, я всё равно не смогу отличить ошибку от штатной ситуации, ведь дальше по коду, в конце метода, у тебя стоит "return null;"
А зачем мне все эти сложности, если при вызове метода getMethodNameByKeyWithPrefix('Vasya') я ожидаю получить строку, которую сразу хочу подставить в вызов метода, Зачем мне делать лишний if. И что значит не нужно прерывать рабочий ход программы, если я не могу получить название метода для доступа к свойству, которое критично для выполнения. С какой стати ты все свойства, записал в некритичные?
 
fixxxer

fixxxer

К.О.
Партнер клуба
Нужно, причем как правило его даже не надо ловить (ну кроме как в самой верхушке показать 500 и залогировать), потому что это логическая ошибка в коде и исправить это в рантайме не представляется возможным.

А вообще главное что оно produces an If. Это мне че по всей вложенности 100500 методов писать if-ы на такой случай? Идите в жо.
 
cDLEON

cDLEON

Онанист РНРСlub
Духовность™
Кто решает какая ситуация поправимая, а какая - нет?
По-моему, любая ситуация может стать поправимой на том или ином уровне "абстракции".
 
weregod

weregod

unserializer
Соглашусь, что если приложение предполагает управление обработкой ошибок, то нужно кидать исключение (хотя выброс исключений на всё, кроме E_USER_ERROR, E_USER_WARNING и E_USER_NOTICE, мне кажется бредом).

Так же замечу, что выброс исключений более ресурсоёмок:
PHP: 
<?php

define('QTY', 10000);

error_reporting(E_ALL);
set_error_handler('handleError');

function handleError($errno, $errstr, $errfile, $errline, $errcontex) {
    
}


// initialize vars to prevent affection on memory usage
$r = array (
    'error'     => array('time' => 0, 'memory usage' => 0),
    'exception' => array('time' => 0, 'memory usage' => 0)
);
$mu = 0;
$pmu = 0;

// error loop {
$t = microtime(TRUE);
$mu = memory_get_usage();
for ($i = 0; $i < QTY; $i++) {
     trigger_error('error', E_USER_NOTICE);
}
$r['error'] = array(
    'time'              => microtime(TRUE) - $t,
    'memory usage'      => memory_get_usage() - $mu
);

// } error loop
// exception loop {

$t = microtime(TRUE);
$mu = memory_get_usage();
for ($i = 0; $i < QTY; $i++) {
    try {
        throw new Exception('exception');
    } catch (Exception $e) {
    }
}
$r['exception'] = array(
    'time'              => microtime(TRUE) - $t,
    'memory usage'      => memory_get_usage() - $mu
);

// } exception loop

var_dump($r);
у меня даёт
PHP: 
array(2) {
  ["error"]=>
  array(2) {
    ["time"]=>
    float(0.019012928009033)
    ["memory usage"]=>
    int(248)
  }
  ["exception"]=>
  array(2) {
    ["time"]=>
    float(0.034639120101929)
    ["memory usage"]=>
    int(1240)
  }
}
потому бросать исключения при перехвате обработчиком ошибок приемлемым считаю только в случае, если приложение предполагает управление обработкой ошибок.
 

atv

Новичок
Так же замечу, что выброс исключений более ресурсоёмок:
Нажмите для раскрытия...
Ну если вся работа твоего приложения заключается в генерации ошибок, то да, нужно оптимизировать и отказываться от исключений :D
У меня в приложениях выброс исключения, это исключительная ситуация, которая может случится раз на сто тыщ пользователей, так что я могу себе позволить растрату в 0.0159 сек. и 1КБ памяти.
 
Фанат

Фанат

oncle terrible
Команда форума
У меня, кстати, лавинообразные исключения (когда, например, сеть недоступна и каждый запрос вызывает исключение), очень быстро съедают память.
Другое дело, что это консольный скрипт и исключений тыщи и всё равно не работает.
А в онлайн приложении тестировать скорость выбрасывания десяти тыщ исключений - это, конечно, просто глупость.

Тому, кто предлагает логировать (log_error()?) вместо триггера, надо учить матчасть. триггер умеет все то же самое, что и лог, НО кроме этого умеет еще и на экран. Это очень удобно.

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

Исключение гибче триггера - его можно ловить не в одном только месте еррор хендлере, а где захохочешь.
Вывод очевиден.
 
fixxxer

fixxxer

К.О.
Партнер клуба
У меня, кстати, лавинообразные исключения (когда, например, сеть недоступна и каждый запрос вызывает исключение), очень быстро съедают память.
Другое дело, что это консольный скрипт и исключений тыщи и всё равно не работает.
Нажмите для раскрытия...
Хехе, у меня на такой случай (тоже для фоновых скриптов) мониторилка есть. Точнее это одна ее небольшая фича. Если число исключений больше N за M времени - останавливает на X секунд работу этого скрипта и громко орёт.
 

Вурдалак

Продвинутый новичок
Духовность™ написал(а):
Использовать ли в ОО системах trigger_error? Или работать исключительно с исключениями?
Нажмите для раскрытия...
Духовность™ написал(а):
ещё раз - не на все ошибки нужно делать исключение, т.е. не нужно прерывать рабочий ход проги.
Нажмите для раскрытия...
Кстати, а зачем было создавать тему, если ты уже для себя всё решил?
 
Войдите или зарегистрируйтесь для ответа.
Сверху