Хранить исключения PHP в массиве - PullRequest
3 голосов
/ 30 апреля 2010

Я действительно не уверен, что это правильный путь, так как исключения - действительно новая тема для меня.Можно ли перехватить несколько исключений (разрешить выполнение сценария продолжить), а затем сохранить исключения в массиве, чтобы иметь возможность возвращать все вызванные исключения?

При этом было бы замечательно иметь возможностьиспользовать исключения не только для отображения ошибки, которая убивает приложение (скрипт)

Спасибо!

Ответы [ 4 ]

11 голосов
/ 30 апреля 2010

Во-первых, обработка исключений не так тривиальна, как кажется, поэтому вам следует потратить на это немного времени. :-)

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

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

Для отслеживания ошибок в вашем приложении вы должны использовать другие методы, а не сохранять их в массиве и извлекать их позже. Используйте ведение журнала (есть отличные платформы, например Log4PHP ) для документирования незначительных ошибок и предупреждений приложения.

Тем не менее, было бы здорово быть в состоянии использовать исключения более чем просто показывает ошибку, которая убивает приложение (скрипт)

Исключение должно убить приложение только в том случае, если вы ничего не можете с этим поделать. Также в большинстве случаев хорошей идеей будет отловить все исключения на самом высоком уровне в вашем скрипте, записать ошибку с трассировкой стека и представить пользователю красивое сообщение об ошибке вместо того, чтобы просто «убить» все. : -)

Только некоторые примеры синтаксиса см. W3Schools PHP Exception Handling . Большая статья на эту тему размещена на Devshed .

6 голосов
/ 30 апреля 2010

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

Само название механизма указывает на то, что произошло что-то «исключительное», что вам нужно немедленно обработать.

2 голосов
/ 30 апреля 2010

Вы можете сделать с ними больше, чем просто убить сценарий - но Сан Хасинто прав, говоря, что не очень хорошая практика хранить их в массиве для последующей обработки.

Может быть, вы должны прочитать это (включая примеры, они будут полезны):

http://php.net/manual/en/language.exceptions.php

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

Удачи!

1 голос
/ 30 апреля 2010

Ларри Уолл пишет об этом в своей последней статье о состоянии лука. Каждый хочет, чтобы у него была структура метания / отлова ошибок. По правде говоря, становится плохой практикой кодирования просто полагаться на фреймворк для обработки плохо проверенного кода. Кроме того, это очень затрудняет отладку.

Мой совет был бы вместо того, чтобы что-то вроде этого:

try {
    $fh = fopen("foo.txt", 'r');
    if (!$fh) {
       throw new Exception("foo.txt not found");
    }
    # ...
} catch (Exception $e) {
    # report errors
}

Просто соберите их в буфер сообщений, как они происходят:

@errors = array();
if (! (is_file("foo.txt") && $fh = fopen("foo.txt", 'r')) ) {
    $errors []= "foo.txt not found";
}
# ...

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

PHP пытается быть слишком похожим на Java, ИМХО.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...