php try catch rapport d'erreurs

Question

J'ai une application qui repose sur un serveur de savon pour produire du contenu. De plus, l'authentification sur le site est basée sur un serveur LDAP distinct. Évidemment, si l'un ou l'autre est en panne ou ne répond pas, le site est en panne. J'essaye de mettre en page une conception telle que je peux avoir le rapport d'erreur pour les admins de site et donner également un bon message à l'utilisateur dans le cas où le site est en panne. Les rapports d'erreurs ne sont en fait qu'un e-mail, une insertion de base de données ou un fichier journal sur le serveur de php $ _COOKIE, $ _SERVER, $ _SESSION, $ _REQUEST avec éventuellement une exception SoapFault. Cette information m'aiderait à déboguer tous les problèmes potentiels avec le site s'ils se produisent.

Actuellement, mon site est conçu comme suit:

SoapClientInterface (defines soap functionality) 
    /\ 
     | 
     | implements 
     | 
Client (the client implementing the interface, try/catch blocks on all soap calls here) 
    /\ 
     | 
     | extends 
     | 
Authorization (asserts soap objects returned from server/ requests going to server 
       are appropriate for the user performing the request) 
    /\ 
     | 
     | extends 
     | 
    {all children classes using the soap interface defined on this level} 

Le diagramme pauvre ci-dessus :-) J'ai un client de classe qui englobe tous mes essayages blocs catch pour les exceptions SoapFault et me demande la meilleure façon pour faire deux choses avec les captures: 1. informer l'utilisateur qu'une action a échoué (toute ma fonctionnalité est dans les blocs if/else et si je détermine qu'une opération a échoué je redirige l'utilisateur vers une page de statut et je les informe que leur l'action a échoué
2. signaler la situation aux administrateurs de site pour le débogage (cette fonctionnalité à l'heure actuelle est une fonction simple définie dans la page de statut qui Lorsque la page d'état reçoit un code d'erreur, nous envoyons les variables Cookier, Serveur, Session et Demande et envoyons ce message par e-mail aux administrateurs du site.

Toute suggestion à ce sujet serait appréciée ou si vous avez besoin d'une clarification s'il vous plaît demander.

EDIT: Dans mon expérience avec la programmation web, mes applications affichent généralement le statut des actions de l'utilisateur sur la page dans laquelle l'action se déroule et ne redirigent pas ailleurs. C'est la première fois que j'ai codé une application pour effectuer une action utilisateur et la rediriger vers une page distincte pour tous les messages d'état. Devrais-je me donner des coups de pied de cette façon, est-ce que quelqu'un voit le mérite d'avoir une seule page d'état pour toutes les actions du site ou d'avoir une classe/fonction qui signale le statut sur la page dans laquelle l'action a eu lieu? (Je pose cette question en ce qui concerne la conception de la page de statut sur son propre et comment signaler les erreurs et quoi de ne pas.)

Answer 1

Eh bien, personnellement, je pense que cela dépend de l'erreur. Selon mon expérience, il existe trois types d'exceptions. Ceux que vous pouvez ignorer, ceux que vous pouvez contourner, et ceux que vous utilisez pour terminer l'exécution (A file_not_found exception peut être ignoré si vous essayez simplement de supprimer le fichier, une exception resource_not_available peut être en mesure d'être travaillé si il existe des sources alternatives pour la ressource, et une exception database_connection_failure nécessiterait la fin de l'application sauf si vous aviez une sauvegarde) ... Quel type d'exception a été intercepté va dicter ce que vous en faites.

Personnellement, j'installe un global exception handler ... Ensuite, dans mon bloc catch, je peux choisir de nettoyer la requête, de la gérer différemment, de continuer (si c'est une exception récupérable) ou de relancer l'exception si Je ne peux pas le gérer correctement (erreur de requête, etc). Si l'exception arrive en haut de la pile (le gestionnaire global), alors je consigne l'erreur (j'utilise une table de base de données pour cela) et lance une erreur interne au serveur 500.

En ce qui concerne la redirection pour les erreurs, je ne peux pas supporter ça. Si l'erreur est une erreur temporelle, pourquoi ne puis-je pas simplement actualiser la page? Pourquoi dois-je revenir (si je peux même) pour essayer à nouveau ...

Tant que vous tampon de sortie correctement, vous devriez presque toujours être en mesure de rendre une page d'erreur sans afficher d'informations sensibles à l'utilisateur (I dis presque, puisque tu ne peux rien rendre pour une erreur fatale) ...Sinon, vous cassez la spécification HTTP (puisque vous dites qu'il y a une redirection temporaire de la page en cours où l'erreur est survenue plutôt que l'en-tête d'état "une erreur s'est produite") ...