Vous abordez plusieurs problèmes ici:
1) Une trace de pile ne doit jamais être visible pour les utilisateurs finaux (pour l'expérience utilisateur et à des fins de sécurité)
Oui, il doit être accessible pour diagnostiquer les problèmes des utilisateurs finaux, mais l'utilisateur final ne doit pas les voir pour deux raisons:
- Ils sont très obscurs et illisibles, l'application aura l'air très peu conviviale.
- L'affichage d'une trace de pile à l'utilisateur final peut présenter un risque de sécurité potentiel. Corrigez-moi si je me trompe, PHP imprime en fait les paramètres de fonction dans la trace de pile - brillant, mais très dangereux - si vous obteniez une exception lors de la connexion à la base de données, qu'êtes-vous susceptible de faire dans le stacktrace?
2) La génération d'une trace de pile est un processus relativement coûteux (bien que peu susceptible de poser un problème dans la plupart des circonstances `` exceptionnelles '')
La génération d'une trace de pile se produit lorsque l'exception est créée / levée (c'est pourquoi la levée d'une exception a un prix), l'impression n'est pas si chère. En fait, vous pouvez remplacer Throwable#fillInStackTrace()
votre exception personnalisée en faisant de la levée une exception presque aussi bon marché qu'une simple instruction GOTO.
3) De nombreux frameworks de journalisation imprimeront la trace de la pile pour vous (le nôtre ne le fait pas et non, nous ne pouvons pas le changer facilement)
Très bon point. Le principal problème ici est le suivant: si le framework enregistre l'exception pour vous, ne faites rien (mais assurez-vous que c'est le cas!) Si vous souhaitez enregistrer l'exception vous-même, utilisez un framework de journalisation comme Logback ou Log4J , pour ne pas les mettre sur la console brute car il est très difficile de le contrôler.
Avec le framework de journalisation, vous pouvez facilement rediriger les traces de pile vers un fichier, une console ou même les envoyer à une adresse e-mail spécifiée. Avec le code en dur, printStackTrace()
vous devez vivre avec le sysout
.
4) L'impression de la trace de pile ne constitue pas une gestion des erreurs. Il doit être combiné avec d'autres informations d'enregistrement et de gestion des exceptions.
Encore une fois: connectez-vous SQLException
correctement (avec la trace complète de la pile, en utilisant le cadre de journalisation) et affichez gentil: " Désolé, nous ne sommes actuellement pas en mesure de traiter votre demande ". Pensez-vous vraiment que l'utilisateur est intéressé par les raisons? Avez-vous vu l'écran d'erreur StackOverflow? C'est très humoristique, mais ne révèle aucun détail. Cependant, il garantit à l'utilisateur que le problème sera étudié.
Mais il va vous appeler immédiatement et vous devez être en mesure de diagnostiquer le problème. Vous avez donc besoin des deux: une journalisation des exceptions appropriée et des messages conviviaux.
Pour conclure les choses: consignez toujours les exceptions (de préférence en utilisant le cadre de journalisation ), mais ne les exposez pas à l'utilisateur final. Réfléchissez bien et aux messages d'erreur dans votre GUI, affichez les traces de pile uniquement en mode développement.