utiliser des try-catch sans utiliser les objets ?

Le
Ploc
Bonjour,

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 ?

A vos avis
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Olivier Miakinen
Le #18585041
Le 04/02/2009 23:11, Ploc a écrit :

[...] 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
Le #18595471
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
Le #18655711
Merci pour ces réponses.
Publicité
Poster une réponse
Anonyme