Quand utiliser les blocs Try Catch

Question

Ok, c'est peut-être une question de débutant, mais je ne trouve pas de documentation PHP sur ce sujet et plusieurs recherches sur Internet ne m'ont donné aucune idée à ce sujet.

Quand dois-je utiliser les blocs try-catch pour améliorer mon application ?

J'ai lu quelqu'un qui disait que nous devrions utiliser les blocs try-catch uniquement pour éviter les erreurs fatales. J'ai lu quelqu'un d'autre qui disait que nous ne devrions l'utiliser que pour les erreurs inattendues (attendez quoi ? inattendues ? si ce sont des erreurs inattendues, comment pourrais-je les prévenir avec try-catch ? devrais-je mettre tout mon code d'application dans un bloc try ?) D'autres disent simplement que les blocs try-catch devraient être utilisés partout parce qu'ils peuvent aussi être étendus (extension de la classe Exception). Enfin, quelqu'un dit que les blocs try-catch de PHP sont totalement inutiles car ils sont très mal implémentés. (Sur ce point, j'ai trouvé une belle question sur les performances).

Il me semble que ce sujet est très étrange et confus. Quelqu'un pourrait-il m'éclairer ?

Answer 1

Il me semble que ce sujet est très étrange et confus. Quelqu'un pourrait-il m'éclairer ?

Définitivement. Je ne suis pas un utilisateur de PHP, mais je peux avoir une petite idée après avoir travaillé avec try/catch en ActionScript, Java et JavaScript. Gardez à l'esprit que les différents langages et plateformes encouragent différentes utilisations de try/catch. Cela dit...

Les seules fois où je recommande l'utilisation de try/catch sont si vous utilisez une fonction du langage natif qui

1. Peut lancer une erreur/exception
2. Il ne vous donne aucun outil pour détecter si vous êtes sur le point de faire quelque chose de stupide qui causerait cette erreur/exception. Par exemple, en ActionScript, la fermeture d'un chargeur qui n'est pas ouvert entraînera une erreur, mais le chargeur n'a pas de propriété isOpen à vérifier et vous êtes donc obligé de l'envelopper dans un try/catch pour faire taire une erreur qui, autrement, n'aurait aucun sens.
3. L'erreur/exception est vraiment sans signification.

Prenons les exemples que vous avez cités et voyons comment ils correspondent à cette liste.

J'ai lu quelqu'un qui disait que nous devrions utiliser les blocs try-catch uniquement pour éviter les erreurs fatales.

Dans le cas de la fonction loader.close() de AS, c'est un bon conseil. C'est une erreur fatale, et tout cela à partir d'un faux pas autrement trivial. D'un autre côté, pratiquement TOUTES les erreurs dans AS mettront votre application à l'arrêt. Les envelopperiez-vous toutes dans un try/catch ? Absolument pas ! Une "erreur fatale" est fatale pour une raison. Elle signifie que quelque chose de terriblement mauvais s'est produit et qu'il est imprudent pour l'application de continuer dans un état potentiellement "indéfini". Il est préférable de savoir qu'une erreur s'est produite et de la corriger plutôt que de la laisser passer.

J'ai lu quelqu'un d'autre dire que nous devrions l'utiliser seulement sur des erreurs inattendues.

C'est encore pire. Ce sont vraisemblablement les erreurs que vous ne voulez PAS faire taire, car les faire taire signifie que vous ne les trouverez jamais. Peut-être que vous ne les faites pas taire, cependant... peut-être que vous les enregistrez. Mais pourquoi essayer/attraper/enregistrer/continuer comme si rien ne s'était passé, permettant au programme de s'exécuter dans une condition potentiellement dangereuse et inattendue ? Laissez l'erreur vous frapper et réparez-la. Il n'y a rien de plus frustrant que d'essayer de déboguer une erreur dans un programme que quelqu'un d'autre a écrit parce qu'il a tout enveloppé dans un bloc try/catch et a négligé d'enregistrer.

D'autres disent simplement que les blocs try-catch devraient être utilisés partout car ils peuvent également être étendus (extension de la classe Exception).

Il y a un mérite potentiel à cela si vous êtes celui qui lance l'erreur, et que vous essayez de vous alerter sur une situation exceptionnelle dans votre programme... mais pourquoi essayer/attraper votre propre erreur ? Laissez-la vous donner un coup de pied dans les dents, puis corrigez-la de manière à ne plus avoir besoin de lancer l'erreur.

Enfin, quelqu'un dit que les blocs try-catch de PHP sont totalement inutiles car ils sont très mal implémentés. (Sur ce point, j'ai trouvé une belle question sur les performances).

Peut-être bien. Mais je ne peux pas répondre à cette question.

Alors... c'est peut-être une question un peu religieuse, et je suis certain que les gens ne seront pas d'accord avec moi, mais de mon point de vue particulier, ce sont les leçons que j'ai apprises au fil des ans sur try/catch.

Answer 2

Des personnes différentes vous diront des choses différentes. Mais voici ce que je pense, spécifiquement dans le cas d'une application web.

Toute votre page devrait être dans un try/catch qui affiche un message d'erreur à l'utilisateur. Le message d'erreur ne doit pas indiquer à l'utilisateur ce qui s'est passé en détail, car c'est un problème de sécurité. Il doit enregistrer les informations relatives à l'erreur dans un fichier journal.

L'autre cas est celui où quelque chose pourrait mal tourner dans le fonctionnement normal des affaires. PHP n'est pas très favorable aux exceptions, donc cela n'arrivera pas souvent. En gros, si vous rencontrez une fonction qui lève une exception lorsqu'elle échoue, vous pouvez attraper l'exception et faire autre chose dans ce cas.

En général, votre question revient à demander comment utiliser un marteau pour améliorer la qualification d'une maison. Utilisez les exceptions pour vous aider à mettre en œuvre des comportements particuliers. Ne cherchez pas d'endroits où utiliser les exceptions.

Answer 3

Je pense que c'est simplement une question de préférences, mais d'après mon expérience, je vous encourage à les utiliser autant que possible.

Dans l'application que nous développons actuellement au travail (utilisant Zend Framework si cela a de l'importance), nous utilisons un seul bloc try..catch pour attraper toutes les exceptions dans l'application qui sont montrées à l'utilisateur comme, par exemple, des erreurs 500 et l'exception est enregistrée avec plus d'informations dans la base de données. Personnellement, j'aime cette approche dans le cas d'une application PHP car les exceptions sont extensibles et vous pouvez écrire n'importe quelle fonctionnalité dont vous avez besoin.

Answer 4

J'utilise principalement Try/Catch pour les appels aux bases de données... surtout pour les entrées, les mises à jour et les suppressions, etc.

Je l'utilise parfois pour le traitement de données complexes avec des tableaux et des boucles utilisant des données dynamiques et des tableaux où il y a une chance que quelque chose se passe mal, par exemple des éléments de tableau manquants ou autre (je vérifie normalement ce genre de choses).

Je les utilise également pour les opérations sur lesquelles je n'ai pas un contrôle total, comme l'importation de données à partir d'une source de données externe ou étrangère où il pourrait y avoir des problèmes avec les données ou l'accès au fichier source.

Je pense que ce que l'on entend par "Erreurs inattendues", c'est lorsque vous ne pouvez pas prévenir les problèmes par de bonnes pratiques de programmation, comme vérifier si un fichier existe avant de l'"inclure", Certains problèmes peuvent être anticipés, alors utilisez de bonnes pratiques pour les prévenir. Ne les laissez pas au hasard en les enveloppant dans un try/catch.

Utilisez plutôt les bonnes pratiques de programmation comme vous devriez le faire partout. N'utilisez pas try/catch comme un raccourci paresseux pour tout, partout. C'est une surenchère.

Answer 5

Vous ne pouvez pas mettre des blocs d'essai partout.

Cependant, lors des tests d'applications, les exceptions générées devraient vous alerter sur les endroits où vous devez essayer des captures. C'est l'une des raisons pour lesquelles vous devez effectuer des tests approfondis de votre application/code.

Si vous voyez un endroit où vous pensez en avoir besoin, j'en mettrais un.

EDIT : ok, vous pouvez les mettre partout, mais vous devez savoir où les mettre dans votre code.