Discussion :

[r0d]

Bonjour,

dans tous mes développements, même lorsque j'ai eu la possibilité d'avoir le temps pour produire du beau code, je n'ai jamais été satisfait de ma gestion des erreurs (sauf pour les petits programmes, bien sûr). Ici il s'agit de c++, mais j'ai le même problème en c#.

Je viens de lire cet article, et son auteur me rassure, dans le sens où je ne suis pas le seul à avoir ce problème. En effet, c++ n'offre que 2 options pour la gestion d'erreurs: la valeur de retour ou l'exception. Et dans beaucoup de cas, en particulier lorsque le programme est très gros, avec des dépendances (dans les deux sens) et de fortes contraintes de rapidité d'exécution, aucune des deux méthodes n'est satisfaisante.

Les ingénieurs de google semblent avoir réfléchi sur le sujet et ont permit, dans leur langage Go, qu'une fonction puisse retourner plusieurs valeurs sans avoir besoin de créer une structure spécifique pour cela. Mais cette solution n'est toujours pas pleinement satisfaisante selon moi.

Le problème, au fond, peut s'appréhender en étudiant le chemin d'exécution d'un programme (en cours d'exécution). Par exemple, si on est dans une fonction f qui sera appelée au niveau de la 20ème couche d'exécution, la gestion d'erreur peut être extrêmement difficile. En effet, cela signifie que les 20 fonctions au-dessus de f doivent être prêtes à gérer les choix que l'on aura fait au niveau de f (soit on court-circuite le path avec une exception, soit on remonte tout le path avec une valeur de retour, avec, dans chaque cas, tous les types d'erreurs potentiels à gérer et les problèmes que peut poser la levée d'une exception au milieu d'un traitement ou d'une allocation).

Pourquoi ce domaine du développement logiciel évolue-t-il si peu? Pourquoi les gurus du c++ n'abordent-ils jamais ce sujet? Avez-vous envisagé, voire même trouvé, des solutions intéressantes à ce problème?

[gbdivers]

(mode vendeur d'aspirateur)
Un peu de lecture :
Retour de fonctions ou exceptions ?
Performances des exceptions C++
[mode vendeur d'aspirateur off)

Lecture en diagonale :
* quelle solution est apportée par Go ?
* en C++, on a pair et tuple pour retourner un code d'erreur complexe (ou créer une struct, c'est pas la mort non plus)
* le problème ne vient pas du fait qu'ils ont du vieux code non exception safe (cf les conventions de codage de google...) et qu'ajouter des exceptions est alors problématique ?

Perso, pas rencontré de problème avec l'utilisation des exceptions. La règle du "je gère l'exception ou je la retourne" me va bien

[r0d]

Cette fois-ci c'est Andrei Alexandrescu qui me conforte dans le fait que je ne suis pas seul à avoir ce problème existentiel: http://channel9.msdn.com/Shows/Going...-Handling-in-C

[Klaim]

Oui et autant je connaissais le scope truc autant son Expected m'apparait comme une solution etonnamment bonne!

Ce que je me demande c'est si ils comptent le proposer dans la STL ou au moins dans boost...

[mitkl]

gbdivers > avec Go on peut faire

Code :

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

1
2
3
4
5
my_json, error := json.Marshal(my_entry)
 
if error {
 // traiter erreur
}

Ce qui permet pour une même fonction de retourner une valeur et un "état".


Concernant ce sujet, il y a aussi eu l'article intéressant Why should I have written ZeroMQ in C, not C++ (part I) qui a beaucoup fait réagir la communauté.

[Klaim]

Concernant ce sujet, il y a aussi eu l'article intéressant Why should I have written ZeroMQ in C, not C++ (part I) qui a beaucoup fait réagir la communauté.

Ooooh je l'avait rate celui la!

[Pyramidev]

Fil très intéressant.

Cette fois-ci c'est Andrei Alexandrescu qui me conforte dans le fait que je ne suis pas seul à avoir ce problème existentiel: http://channel9.msdn.com/Shows/Going...-Handling-in-C

J'ajoute le lien vers les diapositives :
https://onedrive.live.com/?cid=F1B8F...d=root&o=OneUp

Oui et autant je connaissais le scope truc autant son Expected m'apparait comme une solution etonnamment bonne!

Ce que je me demande c'est si ils comptent le proposer dans la STL ou au moins dans boost...

Le 29 juin 2014, pour Boost, il y a eu une proposition pour Expected<T, E> (similaire au Expected<T> de Andrei Alexandrescu) :
http://www.hyc.io/boost/expected-proposal.pdf

Je ne sais pas ce que c'est devenu depuis.