Exceptions: Est-ce une bonne pratique?

Question

Ceci est écrit en PHP, mais c'est vraiment indépendant du langage.

try
{
    try
    {
        $issue = new DM_Issue($core->db->escape_string(
 Ceci est écrit en PHP, mais c'est vraiment indépendant du langage. 

<*>

 Est-ce que nested try, catch block est une bonne pratique à suivre? Cela semble un peu encombrant juste pour une page d’erreur. Cependant, mon problème Datamanager génère une exception si une erreur se produit et j’estime qu’il s’agit d’un bon moyen de détecter les erreurs. 

 L'exception Error_Page est simplement un compilateur de pages d'erreur. 

 Je suis peut-être pédant, mais pensez-vous que c'est un bon moyen de signaler les erreurs et, dans l'affirmative, pouvez-vous suggérer une meilleure façon de l'écrire? 

 Merci 
GET['issue']));
    }
    catch(DM_Exception $e)
    {
        throw new Error_Page($tpl, ERR_NOT_FOUND, $e->getMessage());
    }
}
catch(Error_Page $e)
{
    die($e);
}

Est-ce que nested try, catch block est une bonne pratique à suivre? Cela semble un peu encombrant juste pour une page d’erreur. Cependant, mon problème Datamanager génère une exception si une erreur se produit et j’estime qu’il s’agit d’un bon moyen de détecter les erreurs.

L'exception Error_Page est simplement un compilateur de pages d'erreur.

Je suis peut-être pédant, mais pensez-vous que c'est un bon moyen de signaler les erreurs et, dans l'affirmative, pouvez-vous suggérer une meilleure façon de l'écrire?

Merci

Answer 1

Vous utilisez des exceptions pour la logique de page, et je pense personnellement que ce n'est pas une bonne chose. Les exceptions doivent être utilisées pour signaler des événements incorrects ou inattendus, et non pour contrôler la sortie d'une page d'erreur. Si vous souhaitez générer une page d'erreur basée sur Exceptions, envisagez d'utiliser set_exception_handler . Toute exception non interceptée est exécutée via la méthode de rappel spécifiée. N'oubliez pas que cela n'arrête pas la " fatalness " d'une exception. Après qu'une exception ait été transmise via votre rappel, l'exécution s'arrête normalement après toute exception non interceptée.

Answer 2

Je pense que vous feriez mieux de ne pas nidifier. Si vous attendez plusieurs types d’exceptions, utilisez plusieurs captures.

try{
  Something();
}
catch( SpecificException se )
{blah();}
catch( AnotherException ae )
{blah();}

Answer 3

L’idéal est que les exceptions soient capturées au niveau qui puisse les gérer. Pas avant (perte de temps), et pas après (vous perdez le contexte).

Donc, si $ tpl et ERR_NOT_FOUND sont des informations qui ne sont que "connues". près du nouvel appel DM_Issue, par exemple parce qu’il existe d’autres endroits où vous créez un DM_Issue et que vous voulez ERR_SOMETHING_ELSE, ou parce que la valeur de $ tpl varie, alors vous interceptez la première exception au bon endroit.

Comment se rendre de cet endroit à la mort est une autre question. Une alternative serait de mourir sur place. Mais si vous faites cela, il n'y a aucune possibilité pour le code intervenant de faire quoi que ce soit (comme effacer quelque chose d'une manière ou une autre ou modifier la page d'erreur) après l'erreur mais avant la sortie. C'est également bien d'avoir un flux de contrôle explicite. Donc, je pense que vous êtes bon.

Je suppose que votre exemple n'est pas une application complète. Si c'est le cas, c'est probablement inutilement détaillé, et vous pouvez simplement mourir dans la clause catch DM_Exception. Mais pour une application réelle, j'approuve le principe de ne pas mourir au milieu de nulle part.

Answer 4

En fonction de vos besoins, cela pourrait être correct, mais je suis généralement assez réticent à intercepter une exception, à envelopper le message dans une nouvelle exception et à le relancer car vous perdez la trace de la pile (et potentiellement d'autres informations) de l'exception d'origine. dans l'exception d'emballage. Si vous êtes sûr que vous n'avez pas besoin de ces informations pour examiner l'exception d'habillage, tout se passera probablement bien.

Answer 5

Je ne suis pas sûr de PHP mais par exemple C #, vous pouvez avoir plus d’un catch-block, il n’ya donc pas besoin de combinaisons try / catch imbriquées.

De manière générale, j’estime que le traitement des erreurs avec try / catch / finally relève toujours du bon sens, y compris pour l'affichage de " only " une page d'erreur. C’est un moyen simple de gérer les erreurs et d’éviter les comportements étranges en cas de plantage.

Answer 6

Je ne lirais pas d'exception si le problème n'est pas trouvé. Il s'agit d'un état valide d'une application et vous n'avez pas besoin d'une trace de pile pour afficher un 404.

Ce que vous devez détecter, ce sont des échecs inattendus, tels que les erreurs SQL - c’est à ce moment que la gestion des exceptions devient pratique. Je voudrais changer votre code pour ressembler davantage à ceci:

try {
    $issue = DM_Issue::fetch($core->db->escape_string(
 Je ne lirais pas d'exception si le problème n'est pas trouvé. Il s'agit d'un état valide d'une application et vous n'avez pas besoin d'une trace de pile pour afficher un 404. 

 Ce que vous devez détecter, ce sont des échecs inattendus, tels que les erreurs SQL - c’est à ce moment que la gestion des exceptions devient pratique. Je voudrais changer votre code pour ressembler davantage à ceci: 

<*>GET['issue']));
}
catch (SQLException $e) {
    log_error('SQL Error: DM_Issue::fetch()', $e->get_message());
}
catch (Exception $e) {
    log_error('Exception: DM_Issue::fetch()', $e->get_message());
}

if(!$issue) {
    display_error_page($tpl, ERR_NOT_FOUND);
}
else
{
    // ... do stuff with $issue object.
}

Answer 7

Les exceptions ne doivent être utilisées que s'il existe un événement potentiellement destructeur de site, tel qu'une requête de base de données ne s'exécutant pas correctement ou un élément mal configuré. Un bon exemple est qu’un répertoire de cache ou de journal n’est pas accessible en écriture par le processus Apache.

L'idée ici est que les exceptions consistent pour vous, le développeur, à arrêter le code susceptible de casser tout le site afin que vous puissiez le réparer avant le déploiement. Ils vérifient également que, si l'environnement change (par exemple, si quelqu'un modifie les autorisations du dossier de cache ou modifie le schéma de la base de données), le site est arrêté avant qu'il ne puisse endommager quoi que ce soit.

Donc, non; Les gestionnaires de captures imbriqués ne sont pas une bonne idée. Dans mes pages, mon fichier index.php encapsule son code dans un bloc de cache ... cache - et si quelque chose de mauvais se produit, il vérifie s'il est en production ou non; et m'envoie par e-mail et affiche une page d'erreur générique, ou affiche l'erreur directement à l'écran.

N'oubliez pas: PHP n'est pas C #. C # est (à l'exception (hehe, sans jeu de mots: p) d'ASP.net) pour les applications contenant l'état, alors que PHP est un langage de script sans état.