Ошибки являются естественной частью любого веб-приложения, и вам нужно быть готовым показать ошибки, когда это необходимо. Invision Community имеет несколько мощных встроенных функций для обработки ошибок, с которыми вы должны ознакомиться, чтобы лучше справляться с неожиданными (или даже ожидаемыми, но недействительными) ситуациями.
Invision Community выбрасывает Исключения в случае необходимости и пытается бросить наиболее подходящий класс исключения (включая кастомные классы исключений, которые расширяют стандартные классы исключений PHP). Это означает, что каждый раз, когда вы вызываете встроенные методы, вы должны обернуть эти вызовы в блоки try/catch. Например, вы создании HTTP запроса, он может завершиться с ошибкой по нескольким причинам, и это нормально - важно обернуть запрос в блок try/catch, чтобы убедиться, что любая ошибка обрабатывается корректно.
Невыполнение этого требования, как правило, приводит к тому, что конечному пользователю показывается общая ошибка "Что-то пошло не так", которая является бесполезной (что пошло не так?) и часто неуместна (мы должны показывать ошибку конечному пользователю?).
try
{
// Сделать здесь что-то
throw new \UnexpectedValueException;
}
catch( \UnexpectedValueException $e )
{
// Сделать что-нибудь другое
}
Важно ловить индивидуальные исключения тогда, когда это возможно и либо показывать соответствующие сообщения об ошибках, записывать информацию по мере необходимости, либо выполнять другое действие, если это возможно (в некоторых случаях исключения могут быть ожидаемыми и даже могут быть проигнорированы). Вам следует избегать ловить общий класс \Exception - лучше поймать 3 отдельных более конкретных подкласса Exception.
Когда вам нужно показать ошибку конечному пользователю, в \IPS\Output есть метод error() для облегчения этой необходимости.
public function error( $message, $code, $httpStatusCode=500, $adminMessage=NULL, $httpHeaders=array(), $extra=NULL, $faultyAppOrHookId=NULL )
Первым параметром должен быть строковый ключ языка сообщения об ошибке. Полное сообщение об ошибке для отображения также допустимо в случае, если сообщение поступает от стороннего приложения или вы должны заменить переменные в языковой строке. Второй параметр должен быть уникальным кодом ошибки, которую вы генерируете (использование ключа приложения в уникальном коде полезно для обеспечения его уникальности). Третий параметр - это код состояния HTTP, возвращаемый конечному пользователю. Сообщения об ошибках всегда должны иметь код состояния HTTP 4xx или 5xx, и вы всегда должны использовать наиболее подходящий код состояния. Например, если пользователь запросил неизвестную страницу, вы, скорее всего, вернете код статуса 404, в то время как запрос на страницу, к которой у пользователя нет разрешения на просмотр, скорее всего, вернет код состояния 403.
Параметр $adminMessage позволяет вам показывать разное сообщения для администраторов и для обычных пользователей. Это полезно для указания администраторам причины возникшей ошибки. К примеру, если причина, по которой возникает ошибка, связана с тем, что отключена какая-либо настройка, вы можете сообщить конечному пользователю: «У вас нет прав на доступ к этой странице», но вы можете вместо этого подсказать администратору «Эта страница не может отображена потому, что параметр XYZ отключен в панели управления администратора ".
Массив $httpHeaders позволяет отправлять собственные заголовки с HTTP ответом, если это необходимо. Например, если причина, по которой пользователь попал на страницу с ошибкой, является ограничение скорости, вы можете отправить заголовок Retry-After, тем самым указать пользовательскому агенту, когда он может попробовать зайти ещё раз. Параметр $extra позволяет добавлять дополнительную информацию (например обратную трассировку), которая будет показана администраторам, и $faultyAppOrHookId обычно опускается, если вы вручную вызываете метод error().
Имейте в виду, что вы должны вызывать метод error(), даже если текущий запрос является запросом AJAX. Метод автоматически обработает эту ситуацию и вернет информацию об ошибке в JSON ответе, который будет обрабатываться автоматически (в большинстве случаев, по крайней мере) с помощью основных javascript-библиотек AJAX.
Когда возникает непредвиденная ошибка, вы также должны записывать некоторые дополнительные данные в системных журналах, чтобы позже диагностировать проблему. Ознакомьтесь с документацией Журналирование для получения дополнительной информации о записи данных в системных журналах.