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!

[Klaim]

La suite de son poste le decredibilise fortement selon moi: http://www.250bpm.com/blog:8


Il aurait pu comparer le cout de retrait d'un element si c'etait un vecteur avec la taille de ses elements, je suis sur que ca aurait ete sacrement plus rapide.

[gbdivers]

La suite de son poste le decredibilise fortement selon moi

J'ai survolé, il dit en gros qu'il préfère écrire une structure en C parce que std::list du C++ ne convient pas à son problème ???
Qu'il change de conteneur ou qu'il écrive un conteneur adapté en C++ (EDIT : en fait, il veut utiliser un boost.intrusif. Il doit être possible de créer des centaines de conteneurs différents, c'est pas un drame si le C++ ne propose pas toutes les variantes possibles et imaginables... déjà que plein de personnes ne connaissent déjà pas tous les conteneurs de la STL, s'il fallait en mettre d'autres...)

Je lirais les autres demain

EDIT : survol de la partite 1. Je trouve qu'il n'est pas crédible non plus...
Il rejette les exceptions parce qu'elles sont moins lisibles dans un contexte, il se retrouve alors avec des problèmes très complexes dans un autre contexte, parce qu'il a rejeté les exceptions.
Mouais, bof. A lire en détail, mais s'il comprend pas que les exceptions sont un moyen supplémentaire (et non qui se substitue) à la gestion des erreurs en C

EDIT2 :
@mitkl
En C++, ton code devient :

Code :

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

1
2
3
4
5
pair<my_json, error> result = json.Marshal(my_entry);
 
if result.second { // ou is_error(result)
 // traiter erreur
}

Bref, si c'est pas dans la STL, mais que l'on fait la même chose en 2 lignes... on peut pas dire que c'est un problème

[Flob90]

Bonjour,

En regardant les articles que vous citiez, je suis tombé sur : http://www.drdobbs.com/article/print...ectionName=cpp

Pour moi la seule chose qu'il montre, c'est que l'écriture de code résistant aux exceptions c'est difficile, mais en aucun cas que le système des exceptions du C++ est défaillant.

Pour la solution :

Code :

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

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

J'ai un peu de mal à voir en quoi c'est mieux que le système d'exception du C++ ? (Je ne dis pas pour autant que c'est moins bien)

Pour boost, on a :
http://www.boost.org/doc/libs/1_52_0...exception.html
http://www.boost.org/doc/libs/1_52_0...tml/index.html

Le premier permettant l'ajout simple d'informations aux exceptions (nécessaire si on veut vraiment permettre de corriger l'état du programme), le second d'écrire du code résistant plus simplement (dans l'esprit de ce que propose l'article que j'ai cité.

La question qui pourrait se poser c'est de savoir si un tel système (écriture d'une action et d'un rollback) peut-être intégré dans le coeur d'un langage (et pas comme un outil). Si un concepteur de langage s'est retrouvé confronté au problème, je vois un élément qui pourrait l'en dissuader : ça complexifie la grammaire du langage sans pour autant gagner en lisibilité par rapport à l'écriture d'un outil.

Pour l'absence de l'outil SCOPED_EXIT dans la bibliothèque standard, il a peut-être jugé pas assez mature et ne présentant pas beaucoup plus d'avantage que ce qu'on peut réaliser avec un std::unique_ptr et lambda en C++11 :

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
20
21
22
23
24
25
26
27
 
#include<iostream>
#include<functional>
#include<memory>
 
void bar()
{ std::cout << 1; }
void goo()
{ std::cout << 2; }
void hoo()
{ std::cout << 3; throw int(0); }
void foo()
{
	char dummy;
	typedef std::unique_ptr<char,std::function<void (char*)> >
		ScopedExit;
	bar();
	ScopedExit guard(&dummy,[](char*){goo();});
	hoo();
	guard.release();
}
 
int main()
{
	try { foo(); }
	catch(...) { }
}

[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.