[Sheeft]

Salut à tous,

J'ouvre encore un petit sujet pour discuter 

Cette fois-ci j'avais envie de parler des exceptions.
L'idée me vient parce que l'autre jour en cours d'info, le prof nous a dit qu'en pratique, pour un algorithme de recherche on procèderait avec l'aide des exceptions et ça m'avait parût bizarre.

Je comprends l'idée, je vois pourquoi ça marche, mais c'est vrai que j'avais tendance à croire qu'on les utilisait plutôt pour gérer des erreurs… exceptionnelles
Comme c'est le cas des exceptions de base.

D'ailleurs la syntaxe le sous-entend aussi : try… catch (ou try with avec Caml light dans mon cas, et d'ailleurs c'est un peu bizarre mais bon).

Pour comprendre ce que veux dire, et si ça vous intéresse, voici l'algo de recherche dans une liste avec Caml Light qu'on a vu en cours :

Code: (ocaml)

exception trouve of int;;

let place x t =
   try for i=0 to (vect_length t -1) do
      if t.(i) = x then raise (trouve i);
   done;
   with trouve k -> k;;

Vous, vous utilisez les exception ? Si oui dans quels cas ?

[t4ils]

Il m'est arrivé d'utiliser des exceptions crades mais ça reste rare.
J'appelle exceptions crades les endroits où un simple test permet d'éviter l'exception (parseInt(), division par 0 ...)

Sinon je suis plutôt Pokemon exception :

Code:

try {
    [...]
}catch(Exception e) { // Gotta catch 'em all !
    [...]
}

Je n'utilise pas les exceptions pour m'aider dans mon code (comme ton exemple en Caml), mais plutôt pour vraiment faire un catch d'une erreur que je n'avais pas prévu, et la corriger pour qu'elle n'apparaisse plus ensuite

[Reyhn]

A mon grand désarroi les profs d'info sont plutôt pas terrib' pour expliquer les exceptions et leur utilité.
De mon vécu (je suis peut-être une exception   ) on les voit "parce qu'il le faut" mais on apprend pas vraiment à quoi ça sert en vrai ni comment bien les utiliser. J'ai beau les avoir vues en Java et C++, ça reste très flou ...

[Zipler]

En caml c'est plutôt par commodité que l'on fait ça vu qu'il n'y a pas notamment d'instruction "break" (ni continue d'ailleurs).

[Valryon]

En caml c'est plutôt par commodité que l'on fait ça vu qu'il n'y a pas notamment d'instruction "break" (ni continue d'ailleurs).

A mon avis la réponse est là, même si c'est possible je n'ai jamais vu en Java ou C# une exception utilisée pour sortir proprement d'une boucle.

Elles sont globalement plus réservées aux erreurs ou aux dysfonctionnements : time out, division par 0, référence null, etc.

Même si d'un point de vue algorithmique ça se tient, le même algo de tri en # ou Java sera considérablement ralenti par les try/catch et la gestion d’exception, surtout face à un break/continue.

[Sheeft]

Ouais je pense que tu as raison, c'est un peu dommage cette absence de break parce que c'est bien pratique. Pareil, il n'y a pas de return et pour moi, ça manque.

[EvilTroopa]

Après avoir un peu expérimenté les échanges réseau y'a quelques jours (en java), les exceptions c'était le seul moyen que j'avais pour sortir d'un thread qui écoutait sur un port...

J'ai un peu regardé dans les différentes démos que j'ai pu trouver sur le net, les exceptions sont systématiquement utilisées, à plus ou moins bon escient. Des fois, c'est juste pour sortir et afficher une erreur dans la console. Des fois il y avait une gestion un peu plus poussée des éléments du thread.

Perso, en java, je les utilise assez souvent, mais comme t4ils, surtout pour essayer de pallier à des bugs auxquels j'aurais pas pensé.

[Zipler]

Sinon, pour ce qui est du C/C++, j'ai l'habitude suivante: en C, je n'utilise pas les exceptions mais des codes d'erreur et remplissage de stderr (ou pas); en  c++ je ne les utilise que dans les constructeurs pour faire du RAII, pour le reste, je laisse planter, et la version debug m'indique pourquoi grâce aux asserts que je mets un peu partout.

[t4ils]

Zipler, laisser planté une appli c'est peut être no problemo en solo, mais quand tu développes l'application à destination de collaborateurs de ton entreprise, il est très mal vu de voir des messages de plantage avec stack trace (c'est un peu violent lol)

Les exceptions permettent donc aussi au maximum de ne pas déranger l'utilisateur si dès problèmes surviennent, et de présenter un message plus user friendly tout en loguant et avertissant le codeur du problème rencontré

[Zipler]

Le truc c'est que je fais beaucoup de vérifications dans le code (tous les paramètres de fonctions, variables intermediaires, verification de chaque alloc, utilisation d'un log, passage dans valgrind). Quand je dis que je n'utilse pas les exceptions, c'est juste que dans le cas où une survient et qu'elle n'est pas rattrapée immédiatement, c'est que c'est très grave, donc un plantage est peut-être la meilleure solution . C'est vrai que c'est pas l'idéal pour l'entreprise, mais pour l'instant ça me suffit pour mon utilisation individuelle .

[Campanile]

Zipler, laisser planté une appli c'est peut être no problemo en solo, mais quand tu développes l'application à destination de collaborateurs de ton entreprise, il est très mal vu de voir des messages de plantage avec stack trace (c'est un peu violent lol)

Les exceptions permettent donc aussi au maximum de ne pas déranger l'utilisateur si dès problèmes surviennent, et de présenter un message plus user friendly tout en loguant et avertissant le codeur du problème rencontré

Alors ça ça dépend de l'entreprise  Allez hop petit hs :
Chez moi on balance les (très très fréquentes) stacks trace aux utilisateurs (plusieurs milliers sur la France) 
Alors oui, c'est des cochons les développeurs, mais y'a pire, y'a les chefs de projet, quand on leur fait remarquer que c'est pas sympa pro le pauvre utilisateur (je suis côté intégration), c'est qu'ils remplacent la pile par un "Problème technique - Contactez votre administrateur" sans la moindre info sur la cause de l'anomalie. Ou pire de pire, un try avec un catch tout vide
Je pense que je suis dans la boîte ou on se fout des utilisateur et ou on programme le plus mal d'Europe, et j'en suis pas vraiment fier

[Valryon]

Je pense que je suis dans la boîte ou on se fout des utilisateur et ou on programme le plus mal d'Europe, et j'en suis pas vraiment fier

Tu es en SSII quoi
Même expérience chez un des géants du genre, on laissait les stacktraces en intégration pour pouvoir plus facilement débugguer, mais seulement pour les grosses erreurs imprévues.

Les utilisateurs n'étaient pas super contents du message affiché, mais une capture d'écran et hop on pouvait résoudre plus facilement le problème. Du coup ils étaient un peu contents quand même.

[t4ils]

bah euh les gars, je comprends pas tout à vos méthodes là
Moi j'affiche bien erreur technique à l'utilisateur, mais la stack trace reste dans le code quoi

J'affiche à l'utilisateur le message de l'exception à rapporter à la hotline de l'entreprise, mais pas plus
La stack trace est dans un log, qu'on consultera par la suite.

Vous loguez rien ?

[EvilTroopa]

Chez nous, on n'affiche pas d'erreurs en prod et on log tout dans des fichiers.
Les exceptions et autres erreurs sont aussi envoyées par email sur la boite mail du service informatique.

Chaque page est entourée par un gros try/catch pour être sûr qu'aucune erreur ne ressorte dans le html. C'est un peu bourrin, mais ça marche bien

[PypeBros]

Cette fois-ci j'avais envie de parler des exceptions.
L'idée me vient parce que l'autre jour en cours d'info, le prof nous a dit qu'en pratique, pour un algorithme de recherche on procèderait avec l'aide des exceptions et ça m'avait parût bizarre.

Pour info, les exceptions en OCaml sont ~300x plus rapides qu'en C++ (selon un collègue qui fait de l'OCaml quotidiennement). C'est quelque-chose à prendre en compte, évidemment.