Discussion :

[rolandcire]

Bonjour,

Dans mon souci de progresser, je cherche à introduire la gestion d'erreurs au sein de mes scripts.

• Je souhaite d'une part intégrer une gestion des erreurs par try catch... Cela c'est globalement OK.
• Je souhaite d'autre part pouvoir enregistrer les exception soulevées par try catch au sein d'un fichier de log. Et là je coince

Pour le second point, je vois bien qu'il faut aller vers de l'AJAX... mais après ???
Et puis, le jeu en vaut-il la chandelle ?

[RomainVALERI]

Nous avons une idée à propos de la chandelle, mais nous ignorons quel est ton "jeu" ^^

>>> ce que je veux dire, c'est que tout dépend de ton contexte de développement : dev perso "fun", dev perso "pro", outil d'échange entre partenaires, produit interne à un service, produit normalisé à une entreprise, produit commercial, etc.

[rolandcire]

Nous avons une idée à propos de la chandelle, mais nous ignorons quel est ton "jeu"

Belle expression

Mon jeu est disons en évolution incertaine... Nous dirons qu'il s'agit actuellement d'un "dev perso pro" avec en point de mire un dév typique au sein d'une équipe en entreprise ou d'une communauté

[SpaceFrog]

javascript ne sait rien faire au niveau des fichiers, si tu developpe enlangage serveur il faudra ajaxer

[rolandcire]

Je comprends bien qu'AJAX est ici incontournable, mais je ne trouve pas vraiment de tutoriaux, de scripts ou de discussions proches qui pourraient me servir de béquilles afin de démarrer...

En outre, je me pose vraiment la question du bon niveau, de la bonne méthode de gestion des erreurs. J'espère quelques retours de pratiques. Un simple try catch avec émission "d'alert" vous semble-t-il une solution suffisamment courante et performante dans le cadre d'un développement professionnel collectif ?

[RomainVALERI]

En outre, je me pose vraiment la question du bon niveau, de la bonne méthode de gestion des erreurs. J'espère quelques retours de pratiques. Un simple try catch avec émission "d'alert" vous semble-t-il une solution suffisamment courante et performante dans le cadre d'un développement professionnel collectif ?

Non ^^

>>> Des logs sur le serveur seraient plus "pro", car les alert... c'est du browser-side donc il ne faut pas compter dessus ^^ les utilisateurs n'auront peut-être même pas le javascript activé...

[rolandcire]

Des logs sur le serveur seraient plus "pro", car les alert... c'est du browser-side donc il ne faut pas compter dessus ^^ les utilisateurs n'auront peut-être même pas le javascript activé...

On est bien d'accord.

Il reste néanmoins un problème : celui du dév d'un système en POO utilisé dans des contextes potentiellement différents pour des interfaces quelque peu sophistiquées (notamment pour de l'intranet avec JS activé). Il y a toujours le risque qu'une utilisation donnée génère une exception liée à l'interface et à son utilisation.

Dans ce cas, on peut tester les grands éléments de l'interface via des try catch et alert. Mais je trouve que c'est du bidouillage. Je souhaite donc pouvoir faire remonter les exceptions au serveur pour le cas où certaines utilisations en généreraient certaines non décelées lors des tests...

En la matière, je suis convaincu que de nombreux travaux ont déjà été menés en AJAX... Or, pour l'instant je ne trouve rien de probant qui me permettrait d'avancer. Je crains donc de passer des heures à vouloir réinventer la roue. D'où le fil que j'ai créé...

[SpaceFrog]

il suffit sur le catch de lancer une requete ajax en envoyant au serveur le descriptif de l'erreur.
cote serveur un fappend dans un fichier texte

[RomainVALERI]

Effectivement, comme dans l'exemple donné par SpaceFrog : c'est bien un appel ajax dont tu as besoin dans chaque catch. Un appel à sens unique, qui ne renvoie pas de réponse mais déclenche des traitements côté serveur, quels qu'ils soient (logs, BDD, envoi de messages, déclenchement d'autres traitements, etc.).
Je ne vois pas a priori pourquoi ça t'empecherait d'avoir un comportement normalisé, dans la mesure où le traitement côté serveur n'a pas, par définition, les contraintes du client... ^^

Dans le pire des cas, s'il était nécessaire que tu déclenches un traitement côté client dépendant du traitement serveur, tu retomberais dans le schéma ajax plus classique où on attend une réponse du serveur. En l'occurrence, tu peux très bien renvoyer du js prêt à exécuter par exemple, si ça correspond mieux au comportement "normalisé" dont tu parlais...

(Si besoin : sache que la FAQ et les tutos ajax de developpez sont plutôt bien fouttus)

[rolandcire]

Meeerci
Je m'en vais exploiter tout cela

PS : ce forum est vraiment remarquable :!