Je travaille sur une application ASP.NET traditionnelle qui effectue des appels de service WCF. Dois-je essayer d'attraper l'appel WCF et afficher les détails de l'erreur en haut de la page en cours; laissez l'erreur rediriger l'utilisateur vers une page d'erreur personnalisée; ou laissez-le cadre IIS/.NET?Comment gérer les exceptions WCF dans ASP.NET
Quelle approche est la moins susceptible de confondre le futur développeur?
Jamais à l'écran jaune de la mort. Les informations détaillées sur l'erreur peuvent donner des conseils à un pirate pour casser votre site.
Si la page ne peut pas être affichée sans la demande de service, redirigez-la vers une page d'erreur personnalisée.
Si seulement une petite partie des informations manquait sur une page qui n'est pas la clé de sa fonction, alors mieux afficher un message amical à l'utilisateur que cette information particulière n'est pas disponible pour le moment.
Si vous pensez que l'appel WCF peut générer une exception et que vous savez quels types d'exception vous pouvez obtenir, alors oui, vous devez intercepter l'exception et effectuer l'action appropriée. Habituellement, c'est une bonne idée de dire à l'utilisateur qu'une erreur a fait échouer l'opération et de consigner le détail de l'exception pour un examen plus approfondi par vous ou le support technique.
Cela dépendra des exigences de votre application. Pouvez-vous continuer le traitement si l'appel du service Web échoue? Sinon, vous devriez probablement enregistrer l'exception et rediriger l'utilisateur vers une page de 500. J'utiliserais la méthode Application_Error dans global.asax pour faire ceci. Si vous pouvez continuer le traitement, vous devriez essayer/rattraper votre appel de service Web et gérer l'exception FaultException appropriée. Vous ne devriez jamais laisser les clients voir l'écran jaune en production.