Discussion :

[poukill]

Bonjour à tous!

Le code ici est du code métier et n'a que peu d'intérêt. Ce que je voudrais faire, c'est une sorte de RETRY pour relancer la fonction avec des valeurs plus correctes, lorsqu'une exception est levée:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
void Camera::setNumeroCamera(int numero_cam)
{
	try {
		vigra_precondition( (numero_cam > 0) && (numero_cam < 12 ), "Mauvais numéro de caméra");
		numero_camera = numero_cam;
	}
	catch (std::exception & e)
	{
		std::cerr << e.what() << std::endl;
		numero_cam = 9; // j'ai remis une bonne valeur
                retry();
	}
}

Comment faire en C++ ?

Merci!

[zais_ethael]

Je connaissais quelqu'un qui avait pour habitude de faire sans arret comme ça en pl/sql. Bon ben, suffit de relancer la fonction en l'appelant par son nom. Mais pour ma part, j'aurais plutot tendance à tester les valeurs puis les modifier si nécessaire (ou mieux, ne pas les modifier, le programmeur qui appelle une fonction n'a qu'à passer les bons paramètres).

[poukill]

Je connaissais quelqu'un qui avait pour habitude de faire sans arret comme ça en pl/sql. Bon ben, suffit de relancer la fonction en l'appelant par son nom. Mais pour ma part, j'aurais plutot tendance à tester les valeurs puis les modifier si nécessaire (ou mieux, ne pas les modifier, le programmeur qui appelle une fonction n'a qu'à passer les bons paramètres).

Certains paramètres sont assez difficiles à prévoir, même dans une conception par contrat bien définie... C'est pour ça que les exceptions existent!

Ce qui est sûr, c'est que laisser le programme se planter est quand même une moins bonne solution que d'essayer de corriger l'état du système.

Relancer la fonction... c'est tout con j'y avais pas pensé!

J'aurai pensé qu'il existait un truc plus "subtil"...

Merci Zais!

[themadmax]

Mon point de vue:
- Les exceptions ne sont là que pour gérer les erreurs
- Les exceptions système ne sont pas obligé d'être catcher ( programme plante mais de tout façon qu'est que l'on pourrai faire de mieux ? )
- Ne jamais mètre un bloc catch vide

Pour ton problème, il me semble donc que tu ne devrais pas gérer ceci comme une exception, ceci ressemble même plus a un assert. Mais si tu veux utiliser un try catch je vois rien de mieux qu'une boucle while.

[poukill]

- Les exceptions système ne sont pas obligé d'être catcher ( programme plante mais de tout façon qu'est que l'on pourrai faire de mieux ? )

Une meilleure conception est ce qu'on pourrait faire de mieux.
En tant que fournisseur, on n'est effectivement pas responsable des erreurs du client qui appellerait nos routines en violant nos préconditions.
Mais on est responsable de l'état de sortie de notre système lorsque le client joue le jeu.

De plus, je pense qu'on se doit de faire un effort pour essayer de remettre d'aplomb un programme qui part de travers en appelant de nouveau la routine avec des arguments plus "corrects" (dans la mesure du possible bien entendu )

[Luc Hermitte]

Mouais.
Aujourd'hui, je suis plus un partisant de :
- plantage assuré par un assert pour les erreurs de programmation/conception
- exception pour les erreurs liées au contexte d'exécution

Relancer la fonction avec de meilleurs paramètres ? Certainement pas. Rien qu'avec l'heuristique de détermination de nouvelles valeurs, il y a encore moyen de lever toujours plus d'exceptons. L'assistanat à ses limites.
Qu'ils lisent la doc plutôt et revoient leur code plutôt.

Une erreur bloquante et claire qui explique ce qui ne va pas est 100 préférable à un programme qui continue de fonctionner avec des valeurs altérées à l'insu de l'utilisateur. Car il y a de quoi en perdre du temps avant de trouver l'origine d'un bug aussi viceux que "mais pourquoi les valeurs sont incohérentes par rapport à mes entrées" quand on fait tout pour continuer de fonctionner.

[poukill]

OK Luc, j'ai bien noté.
J'abandonne le fait de relancer la fonction qui lève une exception... J'avais fait ça sur les conseils de B.Meyer, mais il semblerait que ce soit pas (plus) une bonne idée!

Merci !

[Luc Hermitte]

Si tu as une exception, tu nétoies (avec le RAII p.ex.) et tu fais (laisses -- vive le RAII) remonter l'exception.
Cela sera à la fonction de "haut-niveau" responsable de la rupture des pré-condition (certainement à ta fonction qui a été mal-traitée) d'assumer la responsabilité de l'exception et de prendre des mesures en conséquences.

Enfin, c'est comme ça que je vois les choses.

[poukill]

OK.
Admettons qu'une exception soit levée. Comment je fais pour "nettoyer" comme tu dis?
En fait, avec le RAII, il y a (normalement) rien besoin de faire, tous les destructeurs vont être appelés, non?

[Jean-Marc.Bourguet]

OK.
Admettons qu'une exception soit levée. Comment je fais pour "nettoyer" comme tu dis?
En fait, avec le RAII, il y a (normalement) rien besoin de faire, tous les destructeurs vont être appelés, non?

Donc tu mets ce qui est a faire dans des destructeurs...

L'idee de pouvoir retenter une operation qui a cause une exception n'est pas neuve et continuer. La possibilite n'existe pas en C++, mais si j'ai bonne memoire, elle est presente en Eiffel et en PL/I. Je ne me souviens plus des details de comment ca marche, donc je ne peux pas proposer une alternative pour le C++. De ce que je me souviens -- et je peux me tromper -- retenter l'appel global comme zais_ethael le propose n'est pas equivalent, la correction etant plus locale.

[poukill]

Donc tu mets ce qui est a faire dans des destructeurs...

L'idee de pouvoir retenter une operation qui a cause une exception n'est pas neuve et continuer. La possibilite n'existe pas en C++, mais si j'ai bonne memoire, elle est presente en Eiffel et en PL/I. Je ne me souviens plus des details de comment ca marche, donc je ne peux pas proposer une alternative pour le C++. De ce que je me souviens -- et je peux me tromper -- retenter l'appel global comme zais_ethael le propose n'est pas equivalent, la correction etant plus locale.

Hum... Dans ma tête, je pensais effectivement que c'était pas équivalent car, d'après mes souvenirs aussi, un autre échec de retry() devait appelé ensuite la routine de plus haut niveau et ainsi de suite, pour essayer de corriger avant l'apparition de l'erreur.
Ici, appeler de nouveau la même fonction ne joue qu'en local, et n'est après tout, peut-être pas une bonne idée (risque de boucle infinie, etc...)
Je crois que je vais laisser crasher alors!

[JolyLoic]

Un cas où ça peut être intéressant de relancer automatiquement, c'est quand l'exception vient d'un manque de ressources.

Par exemple, tu peut relancer ton algo dans un mode qui ne trace pas en mémoire des infos de débug si tu as manqué de mémoire.

Ou alors tu tentes en premier un algo rapide et gourmand en mémoire, et en cas d'échec, tu te replies sur un algo plus lent mais moins gourmand.

Ou encore tu vides des caches mémoires (qui à ralentire la suite des traitements) avant de relancer le calcul.

Dans D&E, il y a une discussion sur les exceptions qui permettent de reprendre là où elles ont été lancées, et pourquoi elles n'avaient pas été retenues en C++, mais je ne l'ai pas sous la main, et ne me souviens plus pourquoi.

[poukill]

Je ne pense pas être dans ce cas là pour l'instant.
Mais ta réponse répond à mes attentes : le mécanisme n'est pas dispo en C++ !

Merci à tous!

[FabaCoeur]

Heu je n'ai pas suivi totalement la discussion et je ne suis pas trop trop calé en exception, seulement pourquoi ne met-tu pas ton code dans une boucle de la manière suivante:

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
/* CODE ORIGINAL */
 
void Camera::setNumeroCamera(int numero_cam)
{
	try {
		vigra_precondition( (numero_cam > 0) && (numero_cam < 12 ), "Mauvais numéro de caméra");
		numero_camera = numero_cam;
	}
	catch (std::exception & e)
	{
		std::cerr << e.what() << std::endl;
		numero_cam = 9; // j'ai remis une bonne valeur
                retry();
	}
}

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
/* CODE MODIFIE */
 
void Camera::setNumeroCamera(int numero_cam)
{
	bool confirm = false;
 
	while( !confirm )
		try {
			vigra_precondition( (numero_cam > 0) && (numero_cam < 12 ), "Mauvais numéro de caméra");
			numero_camera = numero_cam;
			confirm = true;
		}
		catch (std::exception & e)
		{
			std::cerr << e.what() << std::endl;
			numero_cam = 9; // j'ai remis une bonne valeur
		}
}

++

[Jean-Marc.Bourguet]

Dans D&E, il y a une discussion sur les exceptions qui permettent de reprendre là où elles ont été lancées, et pourquoi elles n'avaient pas été retenues en C++, mais je ne l'ai pas sous la main, et ne me souviens plus pourquoi.

L'experience. Plusieurs membres du comite ont rapporte que dans des projets utilisant un langage le permettant, la possibilite avait ete utilisee au debut puis lors de la maintenance, les cas supprimes petit a petit pour finir sans aucune utilisation (un exemple donne etait Cedar/Mesa).