Il y a quelques semaines, j'avais initié un fil portant sur l'opportunité
d'utiliser le mode objet de php alors que le principe même des scripts
php induit plus naturellement un fonctionnement procédural.
Il en était ressorti que l'utilité d'adopter le mode objet dépendait de
la complexité final du produit à coder. Plus c'est gros et complexe, plus
on a intérêt à modérer la complexité en utilisant le mode objet. Mais
pour un projet plutôt simple, il n'était pas nécessaire d'utiliser le
mode objet.
Je suis parti dans cette seconde direction. Ceci dit, je me pose la
question d'utiliser la logique de fonctionnement try-catch même sans
utiliser le mode objet, parce que c'est finalement bien plus pratique que
de tester un code retour (surtout que true/false n'est souvent pas
suffisant quand une méthode peux générer plusieurs causes d'erreur, il
faut alors tester différentes valeurs numériques de retour... Bref, la
galère).
En clair, est-ce que le try-catch est compatible avec du code php non
objet ?
[...] est-ce que le try-catch est compatible avec du code php non objet ?
Oui, je ne vois pas en quoi ce ne serait pas compatible. D'ailleurs le premier exemple donné dans la doc est dans du code non objet.
À vos avis...
A voté.
Pascal PONCET
Ploc a écrit :
En clair, est-ce que le try-catch est compatible avec du code php non objet ?
Bonjour,
Je dirais oui, dans le sens où la structure du langage le permet. Par contre, je me permettrais une petite réserve liée à l'usage.
En fait, l'intérêt d'un bloc "try/catch" est de gérer des exceptions, donc des sorties de code non implicitement prévues. Contrairement à la gestion d'erreur par des blocs successifs "if/else", le mécanisme de l'exception s'attache à des groupes d'erreurs qui seront autant de types d'exceptions à définir et à gérer.
Or, pour définir ces différentes exceptions, il faut créer des sous-classes héritées de la classe native "Exception". Donc programmer objet, au moins à ce niveau-là. Voir : http://fr.php.net/manual/fr/language.exceptions.extending.php
De plus, contrairement à une pratique héritée de la gestion d'erreur procédurale, le mécanisme de l'exception n'est pas conçu pour envoyer un message et stopper l'exécution du code. Dans le cadre de la robustesse d'une application, il est conçu pour continuer l'exécution, sauf erreur fatale, et offrir un aiguillage permettant de sortir proprement. Et ce type de programmation est plus naturel avec l'orienté objet.
En conclusion, oui, on peut toujours s'approprier une fonctionnalité objet dans un code procédural, mais en acceptant de perdre toutes les qualités intrinsèques ce son mécanisme.
Cordialement, Pascal
Ploc a écrit :
En clair, est-ce que le try-catch est compatible avec du code php non
objet ?
Bonjour,
Je dirais oui, dans le sens où la structure du langage le permet.
Par contre, je me permettrais une petite réserve liée à l'usage.
En fait, l'intérêt d'un bloc "try/catch" est de gérer des exceptions,
donc des sorties de code non implicitement prévues.
Contrairement à la gestion d'erreur par des blocs successifs "if/else",
le mécanisme de l'exception s'attache à des groupes d'erreurs qui seront
autant de types d'exceptions à définir et à gérer.
Or, pour définir ces différentes exceptions, il faut créer des
sous-classes héritées de la classe native "Exception".
Donc programmer objet, au moins à ce niveau-là.
Voir : http://fr.php.net/manual/fr/language.exceptions.extending.php
De plus, contrairement à une pratique héritée de la gestion d'erreur
procédurale, le mécanisme de l'exception n'est pas conçu pour envoyer un
message et stopper l'exécution du code.
Dans le cadre de la robustesse d'une application, il est conçu pour
continuer l'exécution, sauf erreur fatale, et offrir un aiguillage
permettant de sortir proprement.
Et ce type de programmation est plus naturel avec l'orienté objet.
En conclusion, oui, on peut toujours s'approprier une fonctionnalité
objet dans un code procédural, mais en acceptant de perdre toutes les
qualités intrinsèques ce son mécanisme.
En clair, est-ce que le try-catch est compatible avec du code php non objet ?
Bonjour,
Je dirais oui, dans le sens où la structure du langage le permet. Par contre, je me permettrais une petite réserve liée à l'usage.
En fait, l'intérêt d'un bloc "try/catch" est de gérer des exceptions, donc des sorties de code non implicitement prévues. Contrairement à la gestion d'erreur par des blocs successifs "if/else", le mécanisme de l'exception s'attache à des groupes d'erreurs qui seront autant de types d'exceptions à définir et à gérer.
Or, pour définir ces différentes exceptions, il faut créer des sous-classes héritées de la classe native "Exception". Donc programmer objet, au moins à ce niveau-là. Voir : http://fr.php.net/manual/fr/language.exceptions.extending.php
De plus, contrairement à une pratique héritée de la gestion d'erreur procédurale, le mécanisme de l'exception n'est pas conçu pour envoyer un message et stopper l'exécution du code. Dans le cadre de la robustesse d'une application, il est conçu pour continuer l'exécution, sauf erreur fatale, et offrir un aiguillage permettant de sortir proprement. Et ce type de programmation est plus naturel avec l'orienté objet.
En conclusion, oui, on peut toujours s'approprier une fonctionnalité objet dans un code procédural, mais en acceptant de perdre toutes les qualités intrinsèques ce son mécanisme.
