Discussion :

[alassanediakite]

Salut
Pourquoi dans ce code, l'erreur de division par zéro n'est pas interceptée?

Code :

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

1
2
3
4
5
int a;
cin>>a;//je rentre zéro (0)
try
{a=1/a;}
catch(exception e){cout<<e.what();}

Si la classe exception ne gère par la division par zéro, quelle classe interne peu-t-on utiliser?
Merci d'avance.
@+

[bacelar]

On ne catche jamais "exception".
Et on ne catche que pour faire un traitement de l'exception, et loguer/afficher l'exception, c'est pas un traitement.
On ne catche que les exceptions que l'on sait traiter, donc jamais "exception".

Une division par zéro ne "génère" pas une exception C++, mais une interruption logicielle.

https://stackoverflow.com/questions/...-studio-2008-c
La réponde de Volodymyr Frytskyy est ma préférée.

[alassanediakite]

Salut et merci pour la reponse.

On ne catche jamais "exception".
Et on ne catche que pour faire un traitement de l'exception, et loguer/afficher l'exception, c'est pas un traitement.
On ne catche que les exceptions que l'on sait traiter, donc jamais "exception".

J'ai toujours vu la gestion des erreurs comme une manière de s'assurer que le programme ne plante pas.
Ainsi en plus du traitement des exceptions les plus probables il faut prévoir un cas général...

Code :

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

1
2
3
4
5
6
try
{...}
catch(cas1 e1){...}
catch(cas2 e2){...}
...
catch(cas général eg){...}

J'ai tenté la solution de Volodymyr Frytskyy sur VS2010 mais l'exception n'est pas gérée et le lien donne une documentation à télécharger.

Une division par zéro ne "génère" pas une exception C++, mais une interruption logicielle.

Alors questions:

• Il y a-t-il un solution unique pour capter toutes les exceptions en C++
• Sinon comment capter la division par zéro sans vérifier les opérandes?

@+
@+

[bacelar]

J'ai toujours vu la gestion des erreurs comme une manière de s'assurer que le programme ne plante pas.

Et mettre le problème sous le tapis ?
C'est de la connerie en barre.

Quand il y a une erreur que le programmeur n'a pas prévu, on laisse mourir l'application et l'OS génèrera automatiquement un fichier de dump pour que le programmeur ait des informations sur le problème non prévu.

Ainsi en plus du traitement des exceptions les plus probables il faut prévoir un cas général...

NON !!!
Quand on ne sait pas ce que l'on catche ou comment le traiter, on ne catche pas, un point c'est tout.
Si votre code catche une erreur mais que le code appelant le votre, lui, c'est vraiment comment gérer cette erreur, il faut comment ? (Il l'a dans le baba)

J'ai tenté la solution de Volodymyr Frytskyy sur VS2010 ... le lien donne une documentation à télécharger.

C'est un lien cassé.
https://cppcodetips.wordpress.com/20...eptions-in-vc/
Vous pouvez aussi lire les autres réponses du sujet sur StackOverflow qui donnent pas mal de détails.

J'ai tenté la solution de Volodymyr Frytskyy sur VS2010 mais l'exception n'est pas géré

Vous avez bien compris que dans "catch(...)", c'était bien LITTÉRALEMENT "..." et pas autre chose ?

Il y a-t-il un solution unique pour capter toutes les exceptions en C++

Oui, mais je ne le dirai pas, parce que c'est une connerie.
Et une division par 0, ce n'est pas une exception C++, c'est une erreur qui déclenche une interruption logicielle, pas une exception C++. (BIS)

Sinon comment capter la division par zéro sans vérifier les opérandes?

Donc comment faire une connerie ?
Parce que vérifier la validité des entrées/sorties utilisateurs ou des paramètres passés en argument d'une fonction, c'est normalement le minimum syndical du moindre code un tantinet sérieux.
On vous a déjà données une ribambelle de solutions dans le sujet sur StackOverflow :
- utilisation de "__try ... __except" pour récupérer les SEH
- mise en place d'un handler sur les SEH
- demander au compilateur de convertir les SEH en machin "catchable" par du C++
- ...

Mais, bon, tout ça pour coder salement, bof, bof.

[alassanediakite]

Salut
Merci de l'effort.
@+

[koala01]

Salut,

De manière générale, si le développeur d'une fonction ne vérifie pas les informations fournies par l'utilisateur du programme, c'est une erreur de la part du développeur (il faut partir du principe que l'utilisateur est un imbécile distrait, qui n'attend que l'occasion de faire une connerie ... )

Une erreur de la part du développeur, ce n'est pas quelque chose que l'on peut "planquer sous le tapis", c'est un bug, qui doit être résolu avant que l'application ne soit fournie au client final, et qui devrait -- théoriquement -- être mise en évidence pendant la période de tests précédant le déploiement de l'application (encore faut-il -- évidemment -- se tenir à une politique de test unitaires stricte )

Le meilleur moyen pour se prémunir de ce genre de problème nous est fourni par une fonctionnalité tout droit issue du C (l'une des rares fonctionnalités propres au C dont je conseille l'usage et l'abus) : les assertions :

Dans la fonction qui s'occupe de la division, tu peux placer une assertion selon laquelle le diviseur ne peut pas être égal à 0. Si, pour une raison ou une autre, le développeur laisse passer un diviseur égal à 0, cela plantera en période de tests. Grâce aux débuggeur, le développeur pouvoir en retrouver l'origine assez facilement, et donc, corriger le problème.

L'avantage, c'est que, vu que le problème aura été résolu (le code corrigé), cette vérification ne sera plus nécessaire dans l'application déployée. C'est pour cela que les assert du C seront remplacé par une "noop" (aucune instruction) quand l'application sera compilée en mode "release"