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.