Maison > développement back-end > PHP7 > le corps du texte

Exemples pour expliquer comment PHP gère les erreurs et les exceptions dans le framework Yii

醉折花枝作酒筹
Libérer: 2023-02-18 07:20:01
avant
1907 Les gens l'ont consulté

Yii a implémenté par défaut la prise en charge des exceptions et des erreurs sur CApplication, qui est implémentée via set_exception_handler et set_error_handler de php. Grâce à ces deux fonctions intégrées à PHP, les exceptions et erreurs non détectées dans le programme peuvent être prises en charge, améliorant ainsi la maintenabilité du programme.

Exemples pour expliquer comment PHP gère les erreurs et les exceptions dans le framework Yii

Par défaut, Yii attribuera la gestion des exceptions à CApplication::handleException et la gestion des erreurs à CApplication::handleError, mais vous pouvez désactiver l'utilisation de Yii en définissant les deux constantes YII_ENABLE_EXCEPTION_HANDLER et YII_ENABLE_ERROR_HANDLER dans le fichier d'entrée comme false. Mécanisme de gestion des exceptions et des erreurs.

Dans le contenu suivant, les exceptions et les erreurs sont collectivement appelées erreurs, et des distinctions détaillées seront faites si nécessaire. La constante YII_DEBUG (la valeur par défaut est false, peut être définie dans le fichier d'entrée) a un impact très important sur l'affichage des informations d'erreur. En mode débogage, la sortie d'erreur est la plus détaillée. Une fois le programme mis en service, YII_DEBUG doit être modifié en false.

Qu'il soit en mode débogage ou non, lorsque le programme Yii génère une erreur, les informations d'erreur pertinentes seront enregistrées (le niveau d'erreur est erreur et la catégorie par défaut est application). La différence est qu'en mode débogage, les informations détaillées seront affichées directement sur la page Web.

CApplication :: handleError($code,$message,$file,$line)

La méthode ci-dessus implémente la logique appropriée. Portez une attention particulière aux fonctions restaurer_error_handler et restaurer_exception_handler. Si ces deux fonctions ne sont pas appelées, alors lors du processus de gestion des erreurs ultérieur, lorsqu'une exception ou une erreur se produit à nouveau, CApplication:: handleError sera à nouveau appelé, ce qui peut provoquer une boucle infinie. Par conséquent, Yii interdit temporairement l'utilisation de CApplication::handleError pour prendre en charge les erreurs et exceptions ultérieures (en utilisant le mécanisme de gestion des erreurs par défaut de PHP), ce qui garantit qu'aucun appel de boucle ne se produira.

Gestion des erreurs PHP Lorsqu'une erreur se produit, quelles informations PHP enregistrera-t-il dans le journal ? Code d'erreur (c'est-à-dire E_ERROR E_WARNING E_STRICT E_DEPRECATED de PHP) Contenu du message (tel que Undefined vaiable $input) Le chemin du fichier qui a généré l'erreur Le numéro de ligne qui a généré l'erreur Informations de suivi de suivi supplémentaires (obtenues via debug_backtrace) L'URL actuelle

En plus de la journalisation correspondante, Yii effectuera également le traitement ultérieur des erreurs (comme l'interruption de l'exécution, l'affichage des pages d'erreur, etc.). Par défaut, la gestion des erreurs sera confiée au composant CErrorHandler (mais les erreurs peuvent). Réalisé en liant le gestionnaire d'événements onError à CApplicaton Prise en charge secondaire du traitement, la conception ici est flexible).

À ce stade, un CErrorEvent sera généré (et contiendra plusieurs paramètres clés tels que $code, $message, $file et $line) et transmis au composant CErrorHandler pour traitement. Plus précisément, il est géré par CErrorHandler::handleError. Ce processus consiste principalement à organiser les informations liées aux erreurs et à les afficher de manière appropriée.

Le fait qu'il soit en mode débogage (YII_DEBUG==true) a un grand impact sur l'affichage des messages d'erreur. En mode débogage, nous souhaitons afficher des informations détaillées de suivi des erreurs, tandis qu'en mode production, nous souhaitons afficher une page conviviale. Par conséquent, l’affichage des erreurs est différent ici et les différences sont expliquées ci-dessous.

En mode débogage, la vue des exceptions sera directement rendue pour afficher les erreurs. Il sera recherché selon le chemin suivant :

protected/views/system/exception.php

YII_PATH/views/exception.php

Évidemment, le répertoire views/system n'est pas défini dans l'application par défaut, donc le le cadre système sera utilisé. Livré avec les fichiers de vue. Le fichier final inclus sera vues/exception.php du framework Yii.

D'après l'analyse ci-dessus, nous pouvons savoir que si nous voulons utiliser une page d'exception personnalisée en mode débogage (cela n'a généralement pas beaucoup de sens), nous devons configurer le fichier protected/views/system/exception.php, qui peut être utilisé La variable est $data.

En mode sans débogage, le traitement suivant sera effectué :

Si les informations de routage errorAction sont définies pour le composant errorHandler dans le fichier de configuration, exécutez-le directement, sinon exécutez le processus de l'étape 2.

Essayez de charger la vue des erreurs, recherchez selon le chemin suivant (le premier fichier recherché sera utilisé)

protected/views/system/zh_cn/error500.php

protected/views/system/error500.php

protégé /views/system/zh_cn/error.php

protected/views/system/error.php

YII_PATH/views/zh_cn/error500.php

YII_PATH/views/error500.php

YII_PATH/views/zh_cn/ error .php

Y II_PATH/views/error.php

Gestion des exceptions Selon l'analyse précédente, le mécanisme de gestion des exceptions est similaire au mécanisme de gestion des erreurs. Les journaux seront également enregistrés. Le niveau est erreur et la classification est ". exception.$EXCEPTIONCLASS". S'il s'agit d'une exception de classe CHttpException, le nom de la catégorie est exception.CHttpException.$STATUS_CODE. Par exemple, la classification des exceptions des données est appelée exception.CDbException.

Ensuite, l'événement d'erreur CExceptionEvent est transmis au errorHandler pour traitement. Toutes les informations d'erreur sont transmises par l'objet CExceptionEvent. La méthode de traitement est la suivante :

S'il s'agit du mode débogage, les fichiers de vue sont recherchés dans l'ordre suivant, et le premier fichier recherché sera utilisé

protected/views/system/exception.php

YII_PATH/views/ exception.php

S'il s'agit d'un mode sans débogage et que la route de l'attribut errorAction est définie pour le composant errorHandler dans le fichier de configuration, exécutez-le, sinon passez à l'étape 3.

Essayez de charger les fichiers de vue dans l'ordre suivant, le premier fichier recherché sera utilisé

protected/views/system/zh_cn/error500.phpprotected/views/system/error500.phpprotected/views/system/zh_cn/error.phpprotected/views/system/error.phpYII_PATH/views/zh_cn/error500.phpYII_PATH/views/error500.phpYII_PATH/views/zh_cn/error.phpY II_PATH/views/error.php
Copier après la connexion

En utilisant une description d'organigramme, ce sera plus clair : Le processus de recherche de fichiers de vue est plus important car il est lié à la façon dont nous personnalisez les détails de la page d'erreur, l'organigramme suivant décrit le processus en détail.

Exemples pour expliquer comment PHP gère les erreurs et les exceptions dans le framework Yii

Comme vous pouvez le voir sur l'image, le moyen le plus simple est de définir l'attribut errorAction pour le composant errorHandler afin de spécifier l'itinéraire où l'erreur se produit

Exemples pour expliquer comment PHP gère les erreurs et les exceptions dans le framework Yii

De manière générale, ce qui nous préoccupe le plus est le affichage de la page d'erreur en mode production, après l'analyse ci-dessus, deux méthodes sont disponibles :

Définir l'attribut de routage errorAction pour le composant errorHandler dans le fichier de configuration (cette méthode doit être utilisée en premier pour obtenir une configuration flexible)

Définir l'un des fichiers suivants pour implémenter la page d'erreurs personnalisée (non recommandé)

Protected/views/system/zh_cn/error500.php

protected/views/system/error500.php

protected/views/system/zh_cn/error. php

protected/views/system/ error.php

La première méthode est flexible et contrôlable. Vous pouvez spécifier le fichier de vue dans le contrôleur, qui est flexible et contrôlable.

Exemple d'utilisation du gestionnaire d'erreurs

yiiwebErrorHandler est enregistré en tant que composant d'application nommé errorHandler, qui peut être configuré dans la configuration de l'application comme suit :

return [
'components' => [
'errorHandler' => [
'maxSourceLines' => 20,
],
],
];
Copier après la connexion

En utilisant le code ci-dessus, la page d'exception affiche jusqu'à 20 codes sources.

Comme mentionné précédemment, le gestionnaire d'erreurs convertit toutes les erreurs PHP non fatales en exceptions capturables, ce qui signifie que vous pouvez utiliser le code suivant pour gérer les erreurs PHP :

use Yii;
use yii\base\ErrorException;
try {
10/0;
} catch (ErrorException $e) {
Yii::warning("pision by zero.");
}
// execution continues...
Copier après la connexion

Si vous souhaitez afficher une page d'erreur indiquant à l'utilisateur que la requête n'est pas valide ou s'il ne peut pas être géré, vous pouvez simplement lancer une yiiwebHttpException, telle que yiiwebNotFoundHttpException. Le gestionnaire d'erreurs définira correctement le code d'état HTTP de la réponse et utilisera la page d'affichage des erreurs appropriée pour afficher le message d'erreur.

use yii\web\NotFoundHttpException;
throw new NotFoundHttpException();
Copier après la connexion

Affichage d'erreur personnalisé

Le gestionnaire d'erreurs yiiwebErrorHandler ajuste l'affichage des erreurs en fonction de la valeur de la constante YII_DEBUG Lorsque YII_DEBUG est vrai (c'est-à-dire en mode débogage), le gestionnaire d'erreurs affichera les exceptions et les piles d'appels de fonction détaillées ainsi que les lignes de code source. aide au débogage, lorsque YII_DEBUG est faux, seuls les messages d'erreur seront affichés pour éviter la fuite d'informations sensibles de l'application.

Ajouté : si l'exception hérite de yiibaseUserException, quelle que soit la valeur de YII_DEBUG, les informations sur la pile d'appel de fonction ne seront pas affichées. En effet, cette erreur sera considérée comme une erreur générée par l'utilisateur et les développeurs n'auront pas besoin de la corriger. .

Le gestionnaire d'erreurs yiiwebErrorHandler utilise deux vues pour afficher les erreurs par défaut :

@yii/views/errorHandler/error.php : est utilisé pour afficher les messages d'erreur qui n'incluent pas les informations sur la pile d'appels de fonction. Lorsque YII_DEBUG est faux, toutes les erreurs sont. utilisé la vue.

@yii/views/errorHandler/exception.php : utilisé lors de l'affichage de messages d'erreur contenant des informations sur la pile d'appels de fonction.

Vous pouvez configurer les propriétés yiiwebErrorHandler::errorView et yiiwebErrorHandler::exceptionView du gestionnaire d'erreurs pour utiliser une vue d'affichage d'erreur personnalisée.

Utiliser l'action d'erreur

Il est plus pratique d'utiliser l'action d'erreur spécifiée pour personnaliser l'affichage des erreurs. Pour ce faire, configurez d'abord l'attribut yiiwebErrorHandler::errorAction du composant errorHandler, similaire à ce qui suit :

return [
'components' => [
'errorHandler' => [
'errorAction' => 'site/error',
],
]
];
Copier après la connexion

yiiwebErrorHandler:: L'attribut errorAction utilise le routage vers une action. La configuration ci-dessus signifie que les erreurs qui n'ont pas besoin d'afficher les informations de la pile d'appels de fonction seront affichées en exécutant l'opération site/erreur.

Vous pouvez créer une action site/erreur comme suit :

namespace app\controllers;
use Yii;
use yii\web\Controller;
class SiteController extends Controller
{
public function actions()
{
return [
'error' => [
'class' => 'yii\web\ErrorAction',
],
];
}
}
Copier après la connexion

Le code ci-dessus définit l'action d'erreur à l'aide de la classe yiiwebErrorAction, qui restitue une vue nommée error pour afficher les erreurs.

En plus d'utiliser yiiwebErrorAction, vous pouvez définir l'opération d'erreur en utilisant une méthode d'opération similaire à la suivante :

public function actionError()
{
$exception = Yii::$app->errorHandler->exception;
if ($exception !== null) {
return $this->render('error', ['exception' => $exception]);
}
}
Copier après la connexion

Vous devez maintenant créer un fichier de vue sous le nom vues/site/error.php Dans ce fichier de vue, si l'erreur. l'action est définie comme yiiwebErrorAction, vous pouvez accéder aux variables suivantes sont définies dans cette opération :

name : nom de l'erreur

message : message d'erreur

exception : objet d'exception avec des informations plus détaillées, telles que le code d'état HTTP, le code d'erreur, pile d'appels d'erreur, etc.

Supplément : si vous utilisez le modèle d'application de base ou le modèle d'application avancé, les opérations d'erreur et les vues d'erreur ont déjà été définies.

Format d'erreur personnalisé

Le gestionnaire d'erreurs affiche les erreurs selon le format défini par la réponse. Si le format de réponse yiiwebResponse::format est HTML, la vue des erreurs ou des exceptions sera utilisée pour afficher les informations sur l'erreur, comme décrit dans le section précédente. Pour les autres formats de réponse, le gestionnaire d'erreurs attribuera les informations d'erreur sous forme de tableau à l'attribut yiiwebResponse::data, puis les convertira au format correspondant. Par exemple, si le format de réponse est json, vous pouvez voir les informations de réponse suivantes. :

HTTP/1.1 404 Not Found
Date: Sun, 02 Mar 2014 05:31:43 GMT
Server: Apache/2.2.26 (Unix) DAV/2 PHP/5.4.20 mod_ssl/2.2.26 OpenSSL/0.9.8y
Transfer-Encoding: chunked
Content-Type: application/json; charset=UTF-8
{
"name": "Not Found Exception",
"message": "The requested resource was not found.",
"code": 0,
"status": 404
}
Copier après la connexion

Peut être utilisé dans l'application Répondre à l'événement beforeSend du composant de réponse dans la configuration pour personnaliser le format de réponse d'erreur.

return [
// ...
'components' => [
'response' => [
'class' => 'yii\web\Response',
'on beforeSend' => function ($event) {
$response = $event->sender;
if ($response->data !== null) {
$response->data = [
'success' => $response->isSuccessful,
'data' => $response->data,
];
$response->statusCode = 200;
}
},
],
],
];
Copier après la connexion

上述代码会重新格式化错误响应,类似如下:

HTTP/1.1 200 OK
Date: Sun, 02 Mar 2014 05:31:43 GMT
Server: Apache/2.2.26 (Unix) DAV/2 PHP/5.4.20 mod_ssl/2.2.26 OpenSSL/0.9.8y
Transfer-Encoding: chunked
Content-Type: application/json; charset=UTF-8
{
"success": false,
"data": {
"name": "Not Found Exception",
"message": "The requested resource was not found.",
"code": 0,
"status": 404
}
}
Copier après la connexion

推荐学习:php视频教程

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Étiquettes associées:
php
source:csdn.net
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal