Définition d'une hiérarchie d'exceptions

Pierre Barbier de Reuille wrote:

Michael wrote:

Pierre Barbier de Reuille <p.barbierdereuille@free.fr> wrote
in news:44e2590c $0$18265$636a55ce@news.free.fr:

Pour la hi?rarchie, je ferais trois classes abstraites
d?rivant directement de std::exception, une par type
d'exception, de fa?on ? permettre ? l'utilisateur de ta
lib (i.e. le programmeur) d'intercepter l'exceptions
pertinente o? il le veut (par exemple g?rer les exceptions
utilisateur de mani?re centralis?e pour avoir un affichage,
les exceptions qui lui sont destin?es aux endroits o? il
pourra y faire qqch, et les exceptions graves pourront
?ventuellement donner lieu ? un traitement entrainant la
fermeture du programme ...).

Donc le mieux c'est que tout type d'erreur passe par une
exception, puisque par exemple si dans la lib il est
impossible de créer un objet qui doit être utilisé, il est
inutile d'aller plus loin. Et autant avertir tout le monde
de ce qui a foiré.

Quant aux assert, je les utiliserai pour vérifier que les
paramètres entrés par l'utilisateur de la lib sont
corrects...

Voilà, pour moi la distinction est:

- Exception : erreur d'utilisation ou matérielle
- Assert : pour vérifier que *je* ne me suis pas trompé quelque par t,
de toute façon ce sera supprimé dans la version finale (sans avoir ri en
à faire, l'entête <cassert> définit la macro assert comme une fonct ion
vide si la compilation n'est pas en debug ...)

Je vois trois catégories :

-- Code de rétour : erreur « attendue », donc, non
exceptionnelle. L'exemple type, c'est toute erreur dans les
entrées d'une utilisateur. (Utilisateur, ici, c'est le
bonhomme devant le clavier ; pour le code qui t'appelle, je
parlerais de client.) Pour la reste, c'est souvent une
question de jugement : d'une part, une connexion TCP qui
tombe, il faut s'y attendre de temps en temps, mais de
l'autre, si tu es sur un reseau local, et même en général
sur l'internet, c'est quand même assez exceptionnel.

En gros, je dirais que s'il y a des chances de pouvoir
continuer l'opération en cours, c'est le code de rétour qui
s'impose. (Donc, par exemple, on peut toujours démander que
l'utilisateur rentrer les informations erronées de nouveau,
sans avorter la session.)

-- Exception : ce sont les erreurs auxquelles on ne s'attend
pas dans un fonctionnement normal, mais qui peuvent se
produire dans des cas limites, où dans les cas où quelque
chose est cloche dans l'environement (std::bad_alloc, parce
qu'une requête utilisateur est trop compliquée, ou parce
qu'un autre processus sur la machine bouffe toute la
mémoire). En général, on ne lève une exception que quand on
est sûr qu'il va falloir avorter le traitement en cours,
mais qu'on n'a aucune raison particulière à penser que le
problème devient d'une défaut dans le programme (ou
matériel, mais c'est rare de pouvoir detecter des problèmes
réelement matériel).

Ici aussi, il y a des questions de jugements. Mes serveurs,
par exemple, tournent sur des systèmes dédiés, avec
suffisament de mémoire -- la seule cause possible d'un
std::bad_alloc, c'est une fuite de mémoire, et la seule
solution, c'est de terminer le processus et le rédémarrer.
Du coup, je remplace le new_handler par un qui avorte. Mais
il y a bien d'applications qui peuvent récupérer simplement
en abandonnant la requête en cours (avec par exemple un
message d'erreur indiquant une manque de ressources).

-- Assert (avec avortement en cas d'erreur) : tout ce qui
relève de l'erreur logiciel (y compris dans le code client)
ou d'une panne matérielle qui empêcherait au programme de
fonctionner.

Chacune a sa place.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Fabien LE LEZ wrote:

On Wed, 16 Aug 2006 12:59:08 +0200, Fabien LE LEZ
<gramster@gramster.com>:

De toutes façons, quelle que soit la tronche de la liste
d'initialisation, les classes de base sont initialisées
d'abord, puis vient le tour des variables membres, dans
l'ordre de déclaration dans la classe.

Mais bien sûr, respecter cet ordre dans la liste
d'initialisation, même si ça ne change rien au fonctionnement
du programme, améliore sa lisibilité.

Et empêche des avertissements de certains compilateurs.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Je vois trois catégories :

-- Code de rétour : erreur « attendue », donc, non
exceptionnelle. L'exemple type, c'est toute erreur dans les
entrées d'une utilisateur. (Utilisateur, ici, c'est le
bonhomme devant le clavier ; pour le code qui t'appelle, je
parlerais de client.) Pour la reste, c'est souvent une
question de jugement : d'une part, une connexion TCP qui
tombe, il faut s'y attendre de temps en temps, mais de
l'autre, si tu es sur un reseau local, et même en général
sur l'internet, c'est quand même assez exceptionnel.

En gros, je dirais que s'il y a des chances de pouvoir
continuer l'opération en cours, c'est le code de rétour qui
s'impose. (Donc, par exemple, on peut toujours démander que
l'utilisateur rentrer les informations erronées de nouveau,
sans avorter la session.)

Au sein de ma lib, quand un paramètre de fonction est le chemin d'un
fichier vidéo à lire par exemple, et que ce chemin est invalide, je fais
comment?

Je balance une exception, ou bien c'est au client de s'en charger?

Parce que de mon côté, la construction des élèments permettant de lire un
fichier vidéo se font dans le constructeur d'une classe, donc pas de retour
possible ici...

-- Exception : ce sont les erreurs auxquelles on ne s'attend
pas dans un fonctionnement normal, mais qui peuvent se
produire dans des cas limites, où dans les cas où quelque
chose est cloche dans l'environement (std::bad_alloc, parce
qu'une requête utilisateur est trop compliquée, ou parce
qu'un autre processus sur la machine bouffe toute la
mémoire). En général, on ne lève une exception que quand on
est sûr qu'il va falloir avorter le traitement en cours,
mais qu'on n'a aucune raison particulière à penser que le
problème devient d'une défaut dans le programme (ou
matériel, mais c'est rare de pouvoir detecter des problèmes
réelement matériel).

Ici aussi, il y a des questions de jugements. Mes serveurs,
par exemple, tournent sur des systèmes dédiés, avec
suffisament de mémoire -- la seule cause possible d'un
std::bad_alloc, c'est une fuite de mémoire, et la seule
solution, c'est de terminer le processus et le rédémarrer.
Du coup, je remplace le new_handler par un qui avorte. Mais
il y a bien d'applications qui peuvent récupérer simplement
en abandonnant la requête en cours (avec par exemple un
message d'erreur indiquant une manque de ressources).

Ce qui me confirme dans l'idée que dès qu'une erreur apparaît dans
l'enchainement des constructions, connexions, etc... des filtres DirectShow
au sein de la lib, il faut balancer une exception car dès lors la lib ne
peut plus fonctionner...

-- Assert (avec avortement en cas d'erreur) : tout ce qui
relève de l'erreur logiciel (y compris dans le code client)
ou d'une panne matérielle qui empêcherait au programme de
fonctionner.

Je ne m'en sers que comme vérification que les bons paramètres ont été
transmis...

kanze wrote:

Pierre Barbier de Reuille wrote:

Michael wrote:

Pierre Barbier de Reuille <p.barbierdereuille@free.fr> wrote
in news:44e2590c $0$18265$636a55ce@news.free.fr:

Pour la hi?rarchie, je ferais trois classes abstraites
d?rivant directement de std::exception, une par type
d'exception, de fa?on ? permettre ? l'utilisateur de ta
lib (i.e. le programmeur) d'intercepter l'exceptions
pertinente o? il le veut (par exemple g?rer les exceptions
utilisateur de mani?re centralis?e pour avoir un affichage,
les exceptions qui lui sont destin?es aux endroits o? il
pourra y faire qqch, et les exceptions graves pourront
?ventuellement donner lieu ? un traitement entrainant la
fermeture du programme ...).

Donc le mieux c'est que tout type d'erreur passe par une
exception, puisque par exemple si dans la lib il est
impossible de créer un objet qui doit être utilisé, il est
inutile d'aller plus loin. Et autant avertir tout le monde
de ce qui a foiré.

Quant aux assert, je les utiliserai pour vérifier que les
paramètres entrés par l'utilisateur de la lib sont
corrects...

Voilà, pour moi la distinction est:

- Exception : erreur d'utilisation ou matérielle
- Assert : pour vérifier que *je* ne me suis pas trompé quelque part,
de toute façon ce sera supprimé dans la version finale (sans avoir rien
à faire, l'entête <cassert> définit la macro assert comme une fonction
vide si la compilation n'est pas en debug ...)

Je vois trois catégories :

-- Code de rétour : erreur « attendue », donc, non
exceptionnelle. L'exemple type, c'est toute erreur dans les
entrées d'une utilisateur. (Utilisateur, ici, c'est le
bonhomme devant le clavier ; pour le code qui t'appelle, je
parlerais de client.) Pour la reste, c'est souvent une
question de jugement : d'une part, une connexion TCP qui
tombe, il faut s'y attendre de temps en temps, mais de
l'autre, si tu es sur un reseau local, et même en général
sur l'internet, c'est quand même assez exceptionnel.

En gros, je dirais que s'il y a des chances de pouvoir
continuer l'opération en cours, c'est le code de rétour qui
s'impose. (Donc, par exemple, on peut toujours démander que
l'utilisateur rentrer les informations erronées de nouveau,
sans avorter la session.)

Je dois dire que je ne suis pas d'accord (même si, comme tu le dis plus
loin, c'est une affaire de jugement). Mais je ne pense pas qu'il soit
bon de mélanger code de retour et exceptions. Un des objectif des
exceptions est de ne gérer les erreurs qu'à l'endroit où tu peux y faire
quelque chose ... alors qu'avec les codes de retour, il faut propager
les erreurs à la main jusqu'à l'endroit qui peut gérer les erreurs. Et,
typiquement, les erreurs de saisies nécessiteront une re-saisie des
données et l'erreur sera donc gérées au mieux au niveau de l'interface
graphique (pour pouvoir redemander la saisie). Si tu utilises un code de
retour pour ça, ce sera très lourd à gérer. Pour moi, le seul cas où un
code de retour est utilisable dans un système utilisant les exceptions,
est s'il est acceptable d'avoir une erreur "silencieuse". Par exemple,
dans le cas d'un overflow numérique, le fait d'avoir NaN ou inf à la
place d'un nombre valide peut se justifier, car il est probable que le
client remplace ces valeurs par autre chose par la suite ... mais c'est
un des rares exemples que je vois comme ça.

De plus, je ne vois vraiment pas en quoi le code de retour permet, plus
que les exceptions, de récupérer l'exécution (ni plus ni moins
d'ailleurs ...). Il faut aussi savoir que la gestion de code de retour
est coûteuse en temps de calcul tout le temps alors que la gestion des
exceptions ne coûte que quand une exception est levée ...

-- Exception : ce sont les erreurs auxquelles on ne s'attend
pas dans un fonctionnement normal, mais qui peuvent se
produire dans des cas limites, où dans les cas où quelque
chose est cloche dans l'environement (std::bad_alloc, parce
qu'une requête utilisateur est trop compliquée, ou parce
qu'un autre processus sur la machine bouffe toute la
mémoire). En général, on ne lève une exception que quand on
est sûr qu'il va falloir avorter le traitement en cours,
mais qu'on n'a aucune raison particulière à penser que le
problème devient d'une défaut dans le programme (ou
matériel, mais c'est rare de pouvoir detecter des problèmes
réelement matériel).

Ici aussi, il y a des questions de jugements. Mes serveurs,
par exemple, tournent sur des systèmes dédiés, avec
suffisament de mémoire -- la seule cause possible d'un
std::bad_alloc, c'est une fuite de mémoire, et la seule
solution, c'est de terminer le processus et le rédémarrer.
Du coup, je remplace le new_handler par un qui avorte. Mais
il y a bien d'applications qui peuvent récupérer simplement
en abandonnant la requête en cours (avec par exemple un
message d'erreur indiquant une manque de ressources).

-- Assert (avec avortement en cas d'erreur) : tout ce qui
relève de l'erreur logiciel (y compris dans le code client)
ou d'une panne matérielle qui empêcherait au programme de
fonctionner.

Je suis d'accord pour l'erreur logiciel mais pas pour l'erreur
matérielle ! Lors d'une erreur matériel, une exception est appropriée,
quitte à simplement avertir l'utilisateur et quitter ... Le problème de
la gestion d'une panne matérielle avec un assert et qu'il n'y aura plus
aucune erreur de gérées dès que le code est mis en production (i.e. donc
plus en debug).


Pierre

Chacune a sa place.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Je suis d'accord pour l'erreur logiciel mais pas pour l'erreur
matérielle ! Lors d'une erreur matériel, une exception est appropriée,
quitte à simplement avertir l'utilisateur et quitter ... Le problème de
la gestion d'une panne matérielle avec un assert et qu'il n'y aura plus
aucune erreur de gérées dès que le code est mis en production (i.e. donc
plus en debug).

Qu'est ce qui empeche de garder les assert en production ?

Michel Decima wrote:

Je suis d'accord pour l'erreur logiciel mais pas pour l'erreur
matérielle ! Lors d'une erreur matériel, une exception est appropriée,
quitte à simplement avertir l'utilisateur et quitter ... Le problème de
la gestion d'une panne matérielle avec un assert et qu'il n'y aura plus
aucune erreur de gérées dès que le code est mis en production (i.e. donc
plus en debug).

Qu'est ce qui empeche de garder les assert en production ?

Le fait que la fonction assert est redéfinit en fonction vide dès que le
programme n'est plus compilé en debug ... (ce qui en dit long sur
l'usage prévu pour les assert)

Pierre

Sinon ça se fait tout à fait d'avoir un message lisible dans
l'exception. Ça se fait aussi de faire des accesseurs pour que
l'utilisateur de la lib ait un accès facile à l'erreur. Dans ton cas, je
rajouterais, dans DSException, une méthode error_number() qui renvoie
hr. Juste au cas où pour certains erreurs, l'utilisateur de la lib
puisse réinitialiser qqch et relancer le processus ...

C'est donc une chose courament admise qu'une lib formatte elle-même ses
messages d'erreur?

Moi par exemple je peux créer un message du type:

DirectShow Error
Error Code : 0x80040200

CoCreateInstance Error : CLSID_VideoRenderer
GUID : xxxxxxx

Si on veut internationaliser les messages d'erreur, ça devient un problème
non?

Bien que je conçoive que pour des exceptions, dont le message est amené à
apparaître très peu souvent, l'anglais ne soit pas non plus une fatalité...

Michael wrote:

Sinon ça se fait tout à fait d'avoir un message lisible dans
l'exception. Ça se fait aussi de faire des accesseurs pour que
l'utilisateur de la lib ait un accès facile à l'erreur. Dans ton cas, je
rajouterais, dans DSException, une méthode error_number() qui renvoie
hr. Juste au cas où pour certains erreurs, l'utilisateur de la lib
puisse réinitialiser qqch et relancer le processus ...

C'est donc une chose courament admise qu'une lib formatte elle-même ses
messages d'erreur?

Moi par exemple je peux créer un message du type:

DirectShow Error
Error Code : 0x80040200

CoCreateInstance Error : CLSID_VideoRenderer
GUID : xxxxxxx

Si on veut internationaliser les messages d'erreur, ça devient un problème
non?

Bien que je conçoive que pour des exceptions, dont le message est amené à
apparaître très peu souvent, l'anglais ne soit pas non plus une fatalité...

Je pense que c'est en effet un chose bien admise, d'autant que la classe
standard de base std::exception définie dans la norme C++ inclue une
méthode virtuelle "what" qui renvoie une chaîne ...
à toi de renvoyer une chaîne en fonction des locales ...

Pierre

On Wed, 16 Aug 2006 17:07:00 +0100, Pierre Barbier de Reuille
<p.barbierdereuille@free.fr>:

Le fait que la fonction assert est redéfinit en fonction vide dès que le
programme n'est plus compilé en debug ...

Ça, c'est une spécificité de ton compilo.

On 16 Aug 2006 06:14:33 -0700, "kanze" <kanze@gabi-soft.fr>:

-- Exception : ce sont les erreurs auxquelles on ne s'attend
pas dans un fonctionnement normal, mais qui peuvent se
produire dans des cas limites,

Je serais moins manichéen que toi sur la distinction
code de retour / exception. J'ai plutôt tendance à choisir suivant la
lisibilité de code plutôt que d'après une règle fixe.

En particulier, si réparer le problème (par exemple, demander à
l'utilisateur de saisir une nouvelle valeur) demande de remonter
plusieurs appels de fonctions, les exceptions sont parfaitement
adaptées.
Si, en plein milieu d'un calcul, on s'aperçoit que la valeur saisie
entraîne des résultats incorrects, j'aime pouvoir dire "On arrête tout
et on recommence avec une autre valeur", sans avoir à mettre des
dizaines de vérifications de valeurs de retour qui alourdissent le
code.