Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ exceptions

exceptions

16 réponses
Avatar
Nicolas Aunai
salut,


dans le cas où l'utilisateur veut accéder a une case d'un tableau nxm
et que la case demandée dépasse les dimensions du tableau, j'aimerai
lancer une exception...

le truc, c'est que je comprend pas quoi retourner dans le cas où
l'exception est lancée, exemple :


double &
Matrice::operator()(unsigned int i, unsigned int j)
{
try
{
if( i<= n && j <= m)
return lignes[i][j];
else
{
Erreur a(Erreur::notinmat);
throw (a);
}
}
catch(Erreur &tmp)
{
cout << tmp.cause() << " - " << tmp.explic() << endl;
}

}

ici dans le cas où l'utilisateur demande une bonne valeur, c'est la
référence vers la case demandée qui est envoyée, mais dans le cas
contraire, que faire ??

merci

--
Nico,
http://astrosurf.com/nicoastro
messenger : nicolas_aunai@hotmail.com
Signaler un problème avec ce contenu

6 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Fabien LE LEZ
On Tue, 20 Jan 2004 00:46:03 +0100, "Sylvain Togni"
wrote:

AMHA, il voulait dire "bonne solution".


Je ne crois pas, les exceptions conviennent mal aux vérifications
des pre-conditions.


Et quelle autre solution existe-t-il ?

--
;-)

http://www.gotw.ca/gotw/063.htm
http://www.gotw.ca/gotw/067.htm#2


Avatar
Sylvain Togni
On Tue, 20 Jan 2004 00:46:03 +0100, "Sylvain Togni"
wrote:

AMHA, il voulait dire "bonne solution".


Je ne crois pas, les exceptions conviennent mal aux vérifications
des pre-conditions.


Et quelle autre solution existe-t-il ?


Quelque chose qui :

- n'appelle pas les destructeurs, pour ne pas risquer d'empirer
la situation,
- soit déconnectable, pour si après la phase de tests, le profiler
indique une perte de temps important à cet endroit,
- soit utilisable partout, y compris dans les destructeurs.

Bref, assert a encore de beaux jours devant elle :-)

Sylvain



Avatar
kanze
"Sylvain Togni" wrote in message
news:<buhraq$3j9$...
On Tue, 20 Jan 2004 00:46:03 +0100, "Sylvain Togni"
wrote:

AMHA, il voulait dire "bonne solution".


Je ne crois pas, les exceptions conviennent mal aux vérifications
des pre-conditions.


Et quelle autre solution existe-t-il ?


Quelque chose qui :

- n'appelle pas les destructeurs, pour ne pas risquer d'empirer
la situation,
- soit déconnectable, pour si après la phase de tests, le profiler
indique une perte de temps important à cet endroit,
- soit utilisable partout, y compris dans les destructeurs.

Bref, assert a encore de beaux jours devant elle :-)


Merci. Tu l'as dit beaucoup mieux que je ne saurais le dire.

Pour ceux que ça intéresse, il y a eu des discussions il n'y a pas trop
longtemps sur ce sujet dans comp.lang.c++.moderated. C'est intéressant à
voir ce que dit Dave Abrahams (qui est sans doute LE expert mondial en
matière d'exceptions) à cet égard. En gros, le problème est simple : si
il y a violation d'une précondition, c'est que le code est erroné, et
donc, que tes suppositions qui le concerne sont aussi erroné. Du coup,
tout code executer risque d'empirer la situation. Y compris ce dans les
destructeurs qu'on appelle lors du stack walkback. (Aussi, le stack
walkback risque de detruire du contexte qui pourrait t'aider à trouver
l'erreur.)

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16




Avatar
Samuel Krempp
le Tuesday 20 January 2004 01:10, écrivit :
Et quelle autre solution existe-t-il ?


Quelque chose qui :

- n'appelle pas les destructeurs, pour ne pas risquer d'empirer
la situation,
- soit déconnectable, pour si après la phase de tests, le profiler
indique une perte de temps important à cet endroit,
- soit utilisable partout, y compris dans les destructeurs.

Bref, assert a encore de beaux jours devant elle :-)


ce qui n'est pas une mauvaise nouvelle, vu comme c'est simple et efficace à
utiliser :)

Pour le point déconnectable, c'est pas un vrai inconvénient des exceptions.
au contraire, la solution classique de permettre de désactiver chacune des
types des exceptions possibles (façon std::ios_base::exceptions(..) ) est
plus précise que l'unique -DNDEBUG.


Si je comprends bien, les exceptions sont à réserver aux situation où le
programme est en état valide ( - le contrat n'a pas été rompu).
C'est alors un mécanisme puissant pour gèrer les situations d'exceptions
restant dans le cadre du contrat.

Pour revenir au cas du code client qui accède à une case de tableau non
valide, du point de vue du développeur d'une classe matrice je trouvais ça
adapté de lancer une exception (en rendant celà désactivable).
un assert m'irait effectivement aussi bien dans la plupart des cas, mais je
peux qd même imaginer des cas où il y aurait un contrat qui inclue la
possibilité de se tromper d'indices.
Par exple, une application qui accepte des 'plugins' au run-time, supposant
au minimum que le code du plugin est correct, mais se protègeant d'une
mésentente sur un protocole. L'application pourrait éxécuter le code du
plugin jusqu'à recevoir une exception, et se rabattre sur un autre plugin.

Enfin bref, si le développeur d'une bibli utilise des assertions pour tester
des pré-conditions, ça restreint les choix de l'utilisateur de la bibli.
Le bénéfice de la potentielle meilleure restitution de l'état obtenu par
assert est seulement une petite probabilité, globalement je pense que le
compromis allait au bénéfice de flexibilité des exceptions (pour
l'appelant).

Qui est d'avis de conseiller au développeur d'une bibli de matrice de réagir
par un assert plutot que d'une exception ?
moi je pensais un peu que l'assertion dans ces cas là n'était pas vraiment
envisageable.

--
Sam


Avatar
Jean-Marc Bourguet
Samuel Krempp writes:

Qui est d'avis de conseiller au développeur d'une bibli de matrice de réagir
par un assert plutot que d'une exception ?


Ma maniere preferee de traiter des erreurs dans une bibliotheque, est
d'appeler un callback fourni par l'application, celui-ci fait ce qui
est adapte a l'application.

Pour une bibliotheque de matrice, declarer que le comportement est
indefini peut etre adapte (auquel cas en mode debug c'est assert et
pas une exception, lancer ou non une exception ne doit pas dependre du
mode dans lequel est compile l'application).

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Avatar
kanze
Samuel Krempp wrote in message
news:<400f0fe1$0$17139$...

Pour revenir au cas du code client qui accède à une case de tableau
non valide, du point de vue du développeur d'une classe matrice je
trouvais ça adapté de lancer une exception (en rendant celà
désactivable). un assert m'irait effectivement aussi bien dans la
plupart des cas, mais je peux qd même imaginer des cas où il y aurait
un contrat qui inclue la possibilité de se tromper d'indices.


Ça dépend de plusieurs choses -- surtout, comment tu définis le
contrat. AMHA, pour une bibliothèque qui vise un maximum de
flexibilité, la meilleurs solution est un callback. Quelque chose du
genre de new_handler, avec une fonction installée par défaut (qui
abort()), mais que l'utilisateur pourrait remplacer afin de lever une
exception.

Par exple, une application qui accepte des 'plugins' au run-time,
supposant au minimum que le code du plugin est correct, mais se
protègeant d'une mésentente sur un protocole. L'application pourrait
éxécuter le code du plugin jusqu'à recevoir une exception, et se
rabattre sur un autre plugin.


C'est un cas limite, effectivement. Si le plug-in a une grosse erreur,
il n'y a rien à faire, mais pourquoi pas tenter le coup, plutôt que de
crasher le browser.

À condition, évidemment, que l'application n'est pas critique (mais
est-ce qu'on acceptera des plugins dans une application critique ?).

Enfin bref, si le développeur d'une bibli utilise des assertions pour
tester des pré-conditions, ça restreint les choix de l'utilisateur de
la bibli. Le bénéfice de la potentielle meilleure restitution de
l'état obtenu par assert est seulement une petite probabilité,
globalement je pense que le compromis allait au bénéfice de
flexibilité des exceptions (pour l'appelant).

Qui est d'avis de conseiller au développeur d'une bibli de matrice de
réagir par un assert plutot que d'une exception ?


S'il n'offre pas de callback, j'irais pour l'assert. Mais je préfère de
loin la solution de callback.

moi je pensais un peu que l'assertion dans ces cas là n'était pas
vraiment envisageable.


Comme j'ai dit, ça dépend. Si le contrat est que la classe vérifie, et
lève une exception le cas échéant, l'assert n'est pas acceptable. Si le
contrat spécifie que c'est un comportement indéfini, que c'est au charge
de l'appelant de vérifie, alors, l'exception est une très mauvaise
solution.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

1 2