Когда использовать блоки Try Catch

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

Когда я должен использовать блоки try-catch для улучшения моего приложения?

Я читал, что кто-то говорит, что мы должны использовать блоки try-catch только для предотвращения фатальных ошибок. Я читал, что кто-то другой говорит, что мы должны использовать его только при непредвиденных ошибках (подождите, что? Неожиданно? Если они непредвиденные ошибки, как я могу предотвратить их с помощью try-catch? Должен ли я поместить весь код моего приложения внутри блока try?). Другие просто говорят, что блоки try-catch должны использоваться везде, потому что они также могут быть расширены (расширение класса Exception). Наконец, кто-то говорит, что блок try-catch PHP абсолютно бесполезен, потому что они очень плохо реализованы. (На этом я нашел хороший вопрос о производительности).

Мне кажется, что эта тема очень странная и запутанная. Может ли кто-нибудь зажечь меня?

Ответ 1

Мне кажется, что эта тема очень странная и запутанная. Может ли кто-нибудь зажечь меня?

Конечно. Я не являюсь пользователем PHP, но я мог бы немного понять, работая с try/catch в ActionScript, Java и JavaScript. Имейте в виду, что разные языки и платформы поощряют различные применения для try/catch. Тем не менее...

Единственный раз, когда я рекомендую использовать try/catch, если вы используете функцию родного языка, которая

  • Может выдавать ошибку/исключение
  • Не дает вам никаких инструментов для определения того, собираетесь ли вы сделать что-то глупое, что приведет к ошибке/исключению. например: В ActionScript закрытие загрузчика, который не открыт, приведет к ошибке, но загрузчик не имеет свойства isOpen, чтобы проверить, чтобы вы принудительно завернули его в try/catch, чтобы отключить абсолютно бессмысленную ошибку.
  • Ошибка/исключение действительно бессмысленно.

Возьмем приведенные вами примеры и посмотрим, как они соответствуют этому списку.

Я читал, что кто-то говорит, что мы должны использовать блоки try-catch только для предотвращения фатальных ошибок.

В случае функции AS loader.close() это хороший совет. Это фатальная ошибка, и все это от других тривиальных ошибок. С другой стороны, практически ВСЕ ошибки в AS приведут ваше приложение к остановке. Не могли бы вы их обернуть в try/catch? Точно нет! "Фатальная ошибка" является фатальной по причине. Это означает, что произошло что-то ужасное, и для приложения продолжить работу в потенциально "undefined" состояние безрассудно. Лучше знать, что произошла ошибка, а затем исправить, а не просто отпустить.

Я прочитал, что кто-то сказал, что мы должны использовать его только при непредвиденных ошибках

Это еще хуже. Это, как правило, ошибки, которые вы НЕ хотите замолчать, потому что молчание означает, что вы никогда не найдете их. Может быть, вы не глотаете их, хотя... может быть, вы их запустили. Но почему вы пытаетесь /catch/log/continue, как будто ничего не произошло, позволяя программе работать в потенциально опасном и неожиданном состоянии? Просто позвольте ошибке ударить вас в зубы, а затем исправить. Там немного больше разочаровывает, чем пытаться отладить что-то неправильное в программе, которую кто-то написал, потому что они завернули все в блок try/catch, а затем пренебрегли записью.

Другие просто говорят, что блоки try-catch должны использоваться везде, потому что они также могут быть расширены (расширение класса Exception).

Там потенциальная заслуга, если вы тот, кто делает бросок, и вы пытаетесь предупредить себя об исключительной ситуации в вашей программе... но зачем пытаться/поймать свою собственную заброшенную ошибку? Позвольте ему ударить вас по зубам, а затем исправить, чтобы вам больше не нужно было перебрасывать ошибку.

Наконец, кто-то говорит, что блок try-catch PHP абсолютно бесполезен, потому что они очень плохо реализованы. (На этом я нахожу хороший вопрос о производительности).

Может быть, так. Я не могу ответить на этот вопрос.

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

Ответ 2

Разные люди расскажут вам разные вещи. Но это то, что я думаю, особенно в случае веб-приложения.

Вся ваша страница должна быть в try/catch, которая выводит сообщение об ошибке пользователю. Сообщение об ошибке не должно указывать пользователю, что произошло подробно, потому что это проблема безопасности. Он должен записывать информацию об ошибке в файл журнала.

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

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

Ответ 3

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

В приложении, которое мы в настоящее время разрабатываем на работе (используя Zend Framework, если это имеет значение), мы используем один единственный блок try..catch, чтобы поймать все исключения во всем приложении, которые отображаются пользователю, например, как ошибка 500 и исключение с дополнительной информацией в базу данных. Я лично люблю этот подход в случае приложения PHP, поскольку исключения расширяемы, и вы можете в принципе писать любую функциональность, в которой вы нуждаетесь.

Ответ 4

Я преимущественно использую Try/Catch для вызовов в базе данных... особенно входы, обновления и удаления и т.д.

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

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

Я думаю, что подразумевается под "Неожиданными ошибками", где вы не можете предотвратить проблемы с помощью хороших методов программирования, таких как проверка наличия файла до "включения" его. Некоторые проблемы, которые вы МОЖЕТЕ предвидеть, использовать эффективные методы для предотвращения их, Не просто оставляйте их на случай, обернув их в try/catch.

Используйте хорошие методы программирования, как и везде. Не используйте try/catch как ленивый ярлык для всего, везде. Это серьезное переполнение.

Ответ 5

Вы не можете ставить try catch блоки везде.

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

Если вы видите место, где, по вашему мнению, оно вам нужно, я бы поставил его.

РЕДАКТИРОВАТЬ: ОК, вы МОЖЕТЕ разместить их повсюду, но вам нужно знать, куда их поместить в свой код.

Ответ 6

Я обычно помещаю Try и Catch вокруг областей в коде, на которые действуют внешние силы, которые я не контролирую. Например, открытие и чтение внешних файлов.. у вас нет контроля над тем, что в какой-то момент при чтении файла файл становится поврежденным или что-то еще происходит, что вы не можете контролировать, как dc файлового сервера или что-то

Ответ 7

Я согласен с @scriptocalypse. Фактически я использую только блоки try/catch в PHP в двух типах ситуаций.

  • Если возможно, что некоторые внешние (не внутри моего кода) проблемы или ошибки БД могут иметь место:

    • Получение данных из другого источника (например, curl)
    • Получение данных из файлов
    • DB-Исключения
  • Если я работаю внутри другой системы, например CMS или аналогичной, и я хочу переопределить определенное поведение. Например, я не хочу, чтобы было исключено исключение, но сообщение исключения было возвращено в представление.