Discussion :

[coolphp5]

Salut, la question porte sur une syntaxe que l'on trouve dans un magasine php concernant la poo, j'aimerai avoir plusieurs avis sur l'utilité dans ce context car jusque la je n'utilisais pas try/catch de peur de surcharger le serveur inutilement. Voila la synthaxe:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<?php
 
class Maclasse
{
    var $nom;
}
 
try
{
   $monObjet=new MaClasse();
   $monObjet->nom=456"Magazine...";
   echo $monObjet->nom;
}
catch(Execption $e)
{
     echo $e->getMessage();
}
 
?>

bref tout ça pour prouver que try/ catch retourne la ligne d'erreur, sauf que sans cela ça dit la même chose et retourne un parse erreur

merci

[MaitrePylos]

Bonjour,

Voilà un magazine qu'il est bien, le try/catch fait la différence entre un bon développeur et un développeur moyen

En d'autre terme, prévoir la gestion d'erreur dans une application est quelque chose de primordiale.

Dans le bout de code que tu mets cela donne un message d'erreur plus clair , en développement c'est intéressant, maintenant rien ne t'empêche de ne pas mettre le message d'erreur, mais bien de gérer les erreurs éventuelle.

[mon_nom_est_personne]

Bonjour,

Voilà un magazine qu'il est bien, le try/catch fait la différence entre un bon développeur et un développeur moyen

En d'autre terme, prévoir la gestion d'erreur dans une application est quelque chose de primordiale.

Dans le bout de code que tu mets cela donne un message d'erreur plus clair , en développement c'est intéressant, maintenant rien ne t'empêche de ne pas mettre le message d'erreur, mais bien de gérer les erreurs éventuelle.

Assez d'accord les try/catch permettent un vrai monitoring de l'appli mais surtout de pas imprimer des message d'erreur grossier a l'utilisateur et meme mieux de pas se faire indexer dans le cas d'un site public avec des erreur dans la page en cache

[Herode]

Exact

Sans compter que les messages d'erreurs balancés à l'utilisateur (le nombre de mysql_query or die que j'ai pu voir est hallucinant) sont désagréables pour l'utilisateur moyen : c'est incompréhensible, c'est moche car il n'y a pas de couleur et de jolies photos, ça casse la navigation. C'est en outre dangereux car cela peut livrer des informations sensibles sur le code.

Il ne faut pas oublier non plus que même si tu ne lances pas une exception toi-même, certaines fonctions de ta bibliothèque peuvent le faire. Encapsuler les traitements dans un try/catch est donc, en principe, obligatoire.

Quant à surcharger le serveur, je ne vois pas trop pourquoi. Une exception soit rester... une exception ! Cela sert à intercepter et à traiter des erreurs graves, et uniquement à cela.

Last but not least, try/catch permet de traiter proprement les erreurs. C'est particulièrement sensible pour gestion des ressources allouées dynamiquement, par exemple pour garantir le fclose quand un fopen a été fait dans la fonction qui a planté. Cela permet aussi la récupération complète des informations : on a la pile d'appels complète en interceptant l'exception.

[julp]

Hum, il n'y a pas confusion entre erreurs et exceptions ?

Les erreurs PHP ne peuvent être (directement) interceptées par un bloc try/catch à moins de justement traiter l'erreur et de lever une exception ou de redéfinir un gestionnaire d'erreur levant une exception (plutôt à éviter).

De plus, toute erreur fatale, comme celle de syntaxe montrée dans l'exemple du PO ne pourra être réellement gérée : l'interpréteur n'ira pas plus loin et rendra immédiatement la main. De plus des erreurs de syntaxe, notamment, conduisent à la non-interprétation de votre script : donc vous aurez beau chercher à les traiter, les afficher ou je ne sais quoi, ça ne sera jamais pris en compte.

Enfin, quant à l'affichage même des erreurs : la solution magique ce n'est pas try/catch. Là n'est pas réellement son but et PHP se configure pour les cacher.

(Si besoin : Exceptions et PHP5).