Il me manque peut-être quelque part dans le manuel PHP, mais quelle est exactement la différence entre une erreur et une exception? La seule différence que je peux voir est que les erreurs et les exceptions sont gérées différemment. Mais qu'est-ce qui cause une exception et qu'est-ce qui cause une erreur?
Réponses:
Des exceptions sont lancées - elles sont destinées à être capturées. Les erreurs sont généralement irrécupérables. Disons par exemple - vous avez un bloc de code qui insérera une ligne dans une base de données. Il est possible que cet appel échoue (ID en double) - vous voudrez avoir une "Erreur" qui dans ce cas est une "Exception". Lorsque vous insérez ces lignes, vous pouvez faire quelque chose comme ceci
try {
$row->insert();
$inserted = true;
} catch (Exception $e) {
echo "There was an error inserting the row - ".$e->getMessage();
$inserted = false;
}
echo "Some more stuff";L'exécution du programme continuera - parce que vous avez «attrapé» l'exception. Une exception sera traitée comme une erreur sauf si elle est interceptée. Cela vous permettra également de poursuivre l'exécution du programme après son échec.
Throwableinterface), donnant un moyen beaucoup plus expressif et absolu de distinguer et de remettre correctement les deux réels problèmes et messages d'
ErrorVS les descendants de Exception.
Je suis généralement set_error_handlerà une fonction qui prend l'erreur et lève une exception afin que, quoi qu'il arrive, je n'ai que des exceptions à gérer. Plus @file_get_contentsjuste d'essayer / attraper gentil et soigné.
Dans les situations de débogage, j'ai également un gestionnaire d'exceptions qui génère une page similaire à asp.net. Je poste ceci sur la route, mais si demandé, je publierai un exemple de source plus tard.
Éditer:
Ajout comme promis, j'ai coupé et collé une partie de mon code ensemble pour en faire un échantillon. J'ai enregistré le fichier ci-dessous sur mon poste de travail, vous ne pouvez PLUS voir les résultats ici (car le lien est rompu).
<?php
define( 'DEBUG', true );
class ErrorOrWarningException extends Exception
{
protected $_Context = null;
public function getContext()
{
return $this->_Context;
}
public function setContext( $value )
{
$this->_Context = $value;
}
public function __construct( $code, $message, $file, $line, $context )
{
parent::__construct( $message, $code );
$this->file = $file;
$this->line = $line;
$this->setContext( $context );
}
}
/**
* Inspire to write perfect code. everything is an exception, even minor warnings.
**/
function error_to_exception( $code, $message, $file, $line, $context )
{
throw new ErrorOrWarningException( $code, $message, $file, $line, $context );
}
set_error_handler( 'error_to_exception' );
function global_exception_handler( $ex )
{
ob_start();
dump_exception( $ex );
$dump = ob_get_clean();
// send email of dump to administrator?...
// if we are in debug mode we are allowed to dump exceptions to the browser.
if ( defined( 'DEBUG' ) && DEBUG == true )
{
echo $dump;
}
else // if we are in production we give our visitor a nice message without all the details.
{
echo file_get_contents( 'static/errors/fatalexception.html' );
}
exit;
}
function dump_exception( Exception $ex )
{
$file = $ex->getFile();
$line = $ex->getLine();
if ( file_exists( $file ) )
{
$lines = file( $file );
}
?><html>
<head>
<title><?= $ex->getMessage(); ?></title>
<style type="text/css">
body {
width : 800px;
margin : auto;
}
ul.code {
border : inset 1px;
}
ul.code li {
white-space: pre ;
list-style-type : none;
font-family : monospace;
}
ul.code li.line {
color : red;
}
table.trace {
width : 100%;
border-collapse : collapse;
border : solid 1px black;
}
table.thead tr {
background : rgb(240,240,240);
}
table.trace tr.odd {
background : white;
}
table.trace tr.even {
background : rgb(250,250,250);
}
table.trace td {
padding : 2px 4px 2px 4px;
}
</style>
</head>
<body>
<h1>Uncaught <?= get_class( $ex ); ?></h1>
<h2><?= $ex->getMessage(); ?></h2>
<p>
An uncaught <?= get_class( $ex ); ?> was thrown on line <?= $line; ?> of file <?= basename( $file ); ?> that prevented further execution of this request.
</p>
<h2>Where it happened:</h2>
<? if ( isset($lines) ) : ?>
<code><?= $file; ?></code>
<ul class="code">
<? for( $i = $line - 3; $i < $line + 3; $i ++ ) : ?>
<? if ( $i > 0 && $i < count( $lines ) ) : ?>
<? if ( $i == $line-1 ) : ?>
<li class="line"><?= str_replace( "\n", "", $lines[$i] ); ?></li>
<? else : ?>
<li><?= str_replace( "\n", "", $lines[$i] ); ?></li>
<? endif; ?>
<? endif; ?>
<? endfor; ?>
</ul>
<? endif; ?>
<? if ( is_array( $ex->getTrace() ) ) : ?>
<h2>Stack trace:</h2>
<table class="trace">
<thead>
<tr>
<td>File</td>
<td>Line</td>
<td>Class</td>
<td>Function</td>
<td>Arguments</td>
</tr>
</thead>
<tbody>
<? foreach ( $ex->getTrace() as $i => $trace ) : ?>
<tr class="<?= $i % 2 == 0 ? 'even' : 'odd'; ?>">
<td><?= isset($trace[ 'file' ]) ? basename($trace[ 'file' ]) : ''; ?></td>
<td><?= isset($trace[ 'line' ]) ? $trace[ 'line' ] : ''; ?></td>
<td><?= isset($trace[ 'class' ]) ? $trace[ 'class' ] : ''; ?></td>
<td><?= isset($trace[ 'function' ]) ? $trace[ 'function' ] : ''; ?></td>
<td>
<? if( isset($trace[ 'args' ]) ) : ?>
<? foreach ( $trace[ 'args' ] as $i => $arg ) : ?>
<span title="<?= var_export( $arg, true ); ?>"><?= gettype( $arg ); ?></span>
<?= $i < count( $trace['args'] ) -1 ? ',' : ''; ?>
<? endforeach; ?>
<? else : ?>
NULL
<? endif; ?>
</td>
</tr>
<? endforeach;?>
</tbody>
</table>
<? else : ?>
<pre><?= $ex->getTraceAsString(); ?></pre>
<? endif; ?>
</body>
</html><? // back in php
}
set_exception_handler( 'global_exception_handler' );
class X
{
function __construct()
{
trigger_error( 'Whoops!', E_USER_NOTICE );
}
}
$x = new X();
throw new Exception( 'Execution will never get here' );
?>La réponse mérite de parler de l'éléphant dans la pièce
Les erreurs sont l'ancienne façon de gérer une condition d'erreur au moment de l'exécution. En général, le code appelle quelque chose comme set_error_handleravant d'exécuter du code. Suivant la tradition des interruptions en langage assembleur. Voici à quoi ressemblerait un code BASIC.
on error :divide_error
print 1/0
print "this won't print"
:divide_error
if errcode = X
print "divide by zero error"Il était difficile de s'assurer que ce set_error_handlerserait appelé avec la bonne valeur. Et pire encore, un appel pourrait être fait à une procédure distincte qui changerait le gestionnaire d'erreurs. De plus, plusieurs fois, les appels étaient entrecoupés d' set_error_handlerappels et de gestionnaires. Il était facile pour le code de devenir rapidement incontrôlable. La gestion des exceptions est venue à la rescousse en formalisant la syntaxe et la sémantique de ce que le bon code faisait vraiment.
try {
print 1/0;
print "this won't print";
} catch (DivideByZeroException $e) {
print "divide by zero error";
}Aucune fonction distincte ou risque d'appeler le mauvais gestionnaire d'erreurs. Le code est désormais garanti au même endroit. De plus, nous obtenons de meilleurs messages d'erreur.
Auparavant, PHP n'avait que la gestion des erreurs, alors que de nombreux autres langages avaient déjà évolué vers le modèle de gestion des exceptions préférable. Finalement, les fabricants de PHP ont implémenté la gestion des exceptions. Mais susceptibles de prendre en charge l'ancien code, ils ont conservé la gestion des erreurs et ont fourni un moyen de faire ressembler la gestion des erreurs à la gestion des exceptions. Sauf que, il n'y a aucune garantie que certains codes peuvent ne pas réinitialiser le gestionnaire d'erreurs, ce qui était précisément ce que la gestion des exceptions était censée fournir.
Réponse finale
Les erreurs qui ont été codées avant la mise en œuvre de la gestion des exceptions sont probablement des erreurs. Les nouvelles erreurs sont probablement des exceptions. Mais il n'y a pas de conception ou de logique à laquelle sont des erreurs et qui sont des exceptions. Il est simplement basé sur ce qui était disponible au moment où il a été codé et sur la préférence du programmeur qui le codait.
Une chose à ajouter ici concerne la gestion des exceptions et des erreurs. Pour les besoins du développeur d'applications, les erreurs et les exceptions sont des «mauvaises choses» que vous souhaitez enregistrer pour en savoir plus sur les problèmes rencontrés par votre application - afin que vos clients aient une meilleure expérience à long terme.
Il est donc logique d'écrire un gestionnaire d'erreurs qui fait la même chose que ce que vous faites pour les exceptions.
Comme indiqué dans d'autres réponses, définir le gestionnaire d'erreurs sur le lanceur d'exceptions est le meilleur moyen de gérer les erreurs en PHP. J'utilise une configuration un peu plus simple:
set_error_handler(function ($errno, $errstr, $errfile, $errline ) {
if (error_reporting()) {
throw new \ErrorException($errstr, 0, $errno, $errfile, $errline);
}
});Veuillez noter le error_reporting()chèque à conserver@ opérateur travailler. De plus, il n'est pas nécessaire de définir une exception personnalisée, PHP a une classe intéressante pour cela.
Le grand avantage de lancer des exceptions est que l'exception a une trace de pile qui leur est associée, il est donc facile de trouver où est le problème.
Re: "mais quelle est exactement la différence entre une erreur et une exception?"
Il y a beaucoup de bonnes réponses sur les différences ici. Je vais juste ajouter quelque chose dont on n'a pas encore parlé: la performance. Plus précisément, il s'agit de la différence entre lancer / gérer des exceptions et gérer un code de retour (succès ou erreur). Habituellement, en php, cela signifie retourner falseou null, mais ils peuvent être plus détaillés, comme avec le téléchargement de fichiers: http://php.net/manual/en/features.file-upload.errors.php Vous pouvez même renvoyer un objet Exception !
J'ai fait quelques performances dans différentes langues / systèmes. En règle générale, la gestion des exceptions est environ 10 000 fois plus lente que la recherche d'un code de retour d'erreur.
Donc, s'il faut absolument, définitivement, terminer son exécution avant même qu'elle ne commence - eh bien, vous n'avez pas de chance car le voyage dans le temps n'existe pas. Sans voyage dans le temps, les codes de retour sont l'option la plus rapide disponible.
Éditer:
PHP est hautement optimisé pour la gestion des exceptions. Les tests du monde réel montrent que lever une exception n'est que 2 à 10 fois plus lent que de renvoyer une valeur.
Je pense que la réponse que vous recherchez est la suivante;
Les erreurs sont les choses standard auxquelles vous êtes habitué, comme faire écho à une variable $ qui n'existe pas.
Les exceptions sont uniquement à partir de PHP 5 et surviennent lorsqu'il s'agit d'objets.
Pour faire simple:
Les exceptions sont les erreurs que vous obtenez lorsque vous traitez des objets. L'instruction try / catch vous permet cependant de faire quelque chose à leur sujet, et est utilisée un peu comme l'instruction if / else. Essayez de le faire, si le problème n'a pas d'importance, faites-le.
Si vous n'attrapez pas d'exception, cela se transforme en erreur standard.
Les erreurs sont les erreurs fondamentales de php qui stoppent généralement votre script.
Try / catch est souvent utilisé pour établir des connexions de base de données comme PDO, ce qui convient si vous souhaitez rediriger le script ou faire autre chose si la connexion ne fonctionne pas. Mais si vous souhaitez simplement afficher le message d'erreur et arrêter le script, vous n'en avez pas besoin, l'exception non interceptée se transforme en erreur fatale. Vous pouvez également utiliser un paramètre de gestion des erreurs à l'échelle du site.
J'espère que cela pourra aider
Dans PHP 7.1 et versions ultérieures, un bloc catch peut spécifier plusieurs exceptions en utilisant le caractère pipe (|). Ceci est utile lorsque différentes exceptions de différentes hiérarchies de classes sont gérées de la même manière.
try {
// do something
} catch (Error | Exception $e) {
echo $e->getMessage();
}Les exceptions sont lancées intentionnellement par le code en utilisant un jet, des erreurs ... pas tellement.
Les erreurs surviennent à la suite de quelque chose qui n'est généralement pas géré. (Erreurs d'E / S, erreurs TCP / IP, erreurs de référence nulles)
J'ai l'intention de vous donner une discussion des plus inhabituelles sur le contrôle des erreurs.
J'ai construit un très bon gestionnaire d'erreurs dans un langage il y a des années, et bien que certains des noms aient changé, les principes du traitement des erreurs sont les mêmes aujourd'hui. J'avais un système d'exploitation multi-tâches personnalisé et je devais être en mesure de récupérer des erreurs de données à tous les niveaux sans fuites de mémoire, croissance de la pile ou plantages. Ce qui suit est donc ma compréhension de la manière dont les erreurs et les exceptions doivent fonctionner et en quoi elles diffèrent. Je dirai simplement que je ne comprends pas comment les composants internes de try catch fonctionnent, donc je suppose dans une certaine mesure.
La première chose qui se passe sous les couvertures du traitement des erreurs est de passer d'un état de programme à un autre. Comment cela se fait-il? J'y reviendrai.
Historiquement, les erreurs sont plus anciennes et plus simples, et les exceptions sont plus récentes et un peu plus complexes et capables. Les erreurs fonctionnent bien jusqu'à ce que vous ayez besoin de les faire remonter, ce qui équivaut à confier un problème difficile à votre superviseur.
Les erreurs peuvent être des nombres, comme des numéros d'erreur, et parfois avec une ou plusieurs chaînes associées. Par exemple, si une erreur de lecture de fichier se produit, vous pourrez peut-être signaler ce que c'est et éventuellement échouer correctement. (Hay, c'est un pas en avant par rapport au crash comme autrefois.)
Ce qui n'est pas souvent dit à propos des exceptions, c'est que les exceptions sont des objets superposés sur une pile d'exceptions spéciale. C'est comme une pile de retour pour le flux du programme, mais elle contient un état de retour uniquement pour les essais et les captures d'erreur. (J'avais l'habitude de les appeler ePush et ePop, et? Abort était un lancer conditionnel qui ePop et récupérait à ce niveau, tandis que Abort était un dé complet ou une sortie.)
Au bas de la pile se trouvent les informations sur l'appelant initial, l'objet qui connaît l'état lorsque l'essai externe a été lancé, ce qui correspond souvent au démarrage de votre programme. En plus de cela, ou la couche suivante de la pile, avec up étant les enfants et down étant les parents, se trouve l'objet d'exception du prochain bloc try / catch interne.
Si vous faites un essai à l'intérieur d'un essai, vous empilez l'essai intérieur au-dessus de l'essai extérieur. Lorsqu'une erreur se produit dans l'essai interne et que soit le catch interne ne peut pas le gérer, soit l'erreur est renvoyée à l'essai externe, le contrôle est passé au bloc catch externe (objet) pour voir s'il peut gérer l'erreur, c'est-à-dire votre superviseur.
Donc, ce que cette pile d'erreurs fait vraiment est de pouvoir marquer et restaurer le flux du programme et l'état du système, en d'autres termes, elle permet à un programme de ne pas planter la pile de retour et de gâcher les choses pour les autres (données) lorsque les choses tournent mal. Ainsi, il enregistre également l'état de toutes les autres ressources telles que les pools d'allocation de mémoire et peut donc les nettoyer lorsque la capture est terminée. En général, cela peut être une chose très compliquée, et c'est pourquoi la gestion des exceptions est souvent lente. En général, un peu d'état doit entrer dans ces blocs d'exceptions.
Donc, une sorte de bloc try / catch définit un état auquel il est possible de revenir si tout le reste est gâché. C'est comme un parent. Quand nos vies sont gâchées, nous pouvons retomber sur les genoux de nos parents et ils le feront à nouveau.
J'espère que je ne vous ai pas déçu.
Une fois set_error_handler () défini, le gestionnaire d'erreur est similaire à celui d'Exception. Voir le code ci-dessous:
<?php
function handleErrors( $e_code ) {
echo "error code: " . $e_code . "<br>";
}
set_error_handler( "handleErrors" );
trigger_error( "trigger a fatal error", E_USER_ERROR);
echo "after error."; //it would run if set_error_handler is defined, otherwise, it wouldn't show
?>
Errors are generally unrecoverable<- en fait, ce n'est pas vraiment vrai.E_ERRORetE_PARSEsont les deux erreurs irrécupérables les plus courantes (il y en a quelques autres) mais la grande majorité des erreurs que vous verrez dans le développement sont récupérables (E_NOTICE,E_WARNINGet al). Malheureusement, la gestion des erreurs de PHP est un désordre complet - toutes sortes de choses déclenchent des erreurs inutilement (la grande majorité des fonctions du système de fichiers, par exemple). En général, les exceptions sont "la manière OOP", mais malheureusement certaines des API natives de PHP utilisent des erreurs au lieu d'exceptions :-(