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"

[alassanediakite]

Salut
Merci koala01, ton respect me soulage. Franchement j'avais eu le dégout de dev.com.
Pour ce qui est de la gestion des imprévus (exception). Dans un développement réel on utilise habituellement des composants d’autrui (exemple un driver odbc ou jdbc...). Pour vous dire qu'on n'est pas maitre de tout ce qui compose notre produit. S'il faut alors laisser mourir votre application à chaque nouvelle exception non gérée je pense que le client changera vite de produit.
Je constate que la division par zéro plante codeblock et fait dire "exception non gérée" par VS 2010.
Je continu ma recherche.
@+

[Bousk]

Je pensais faire des développements réels, mais peut-être me trompe-je depuis toutes ces années

Explique-nous comment tu peux gérer une exception non prévue ? Comment tu traites une exception non gérée ?
Par définition, une exception non prévue survient n'importe quand et n'importe où et nous n'avons aucune information à son sujet. Partant de là, quel traitement espères-tu donc réaliser en dehors d'une réinitialisation complète de l'appli/machine ?

[bacelar]

Merci koala01, ton respect me soulage. Franchement j'avais eu le dégout de dev.com.

Heu, mince.
J'ai franchement déjà été largement plus cassant avec d'autres qu'avec toi.

Dans un développement réel on utilise habituellement des composants d’autrui (exemple un driver odbc ou jdbc...). Pour vous dire qu'on n'est pas maitre de tout ce qui compose notre produit. S'il faut alors laisser mourir votre application à chaque nouvelle exception non gérée je pense que le client changera vite de produit.

Le client va vite partir aussi quand l'application va l'accabler de message d'erreurs cryptiques ou freezer l'interface par des "traitements" d'erreurs foireux ou qui rempli le disque dur de log inexploitable.
Le tout en maitrisant absolument pas ce qui passe, potentiellement détruisant toutes les données, ou pire, les vérolant.
Un message d'erreur de Windows indiquant que le problème a été remonté au développeur (utilisation de WIR) et qu'il fera son maximum pour le régler dans les plus brefs délais est bien plus rassérénant.

Si vous utilisez des composants aussi installables et mal finis, je vous conseille de faire du "surrogate" (hébergement de Dll dans un processus dédié et communication IPC entre l'application et le processus hôte) pour que leur boulettes ne vous plombe pas votre application.
Les Driver ODBC utilisent déjà cette techniques dans la plupart des cas, où seule la partie supérieur de la couche Middleware est injectée dans l'espace de l'exécutable.
Mais bon, des composants aussi mal foutus, ça reste pas longtemps sur le marché.

Le but, c'est de détecter les problèmes lors des tests, pas en production, donc, on ne catche pas, sinon, on prend des années pour fiabiliser une application pour rien.

Je constate que la division par zéro plante codeblock et fait dire "exception non gérée" par VS 2010.

Les IDE/débuggeur, c'est un peu particulier, car ils font plus ou moins déjà du "surrogate" car ils lancent le programme à déboguer en lui attachant le débogueur.
Le programme à déboguer est un espèce de "surrogate" du débogueur.
Vos constatations, c'est quoi ? Le comportement de debuggee, du débuggeur, de l'IDE ???

Je continu ma recherche.
@+

Vous cherchez quoi ?
Le sujet de StackOverflow fait déjà largement le tour de la question.

Si vous voulez pas vous prendre la tête, vous n'avez qu'à changer les options de compilation qui vont bien et catcher l'int (et pas l'exception) qui est lancé.
Mais, franchement, bottez-vous les fesses à faire correctement les choses : validation des entrées utilisateur et des paramètres en entré des fonctions.

[koala01]

Il faut comprendre que les exceptions devraient être réservées aux situations dont on sait qu'elles peuvent survenir, tout en espérant qu'elles ne surviennent jamais mais dont la loi de l'emmerdement maximum nous dit que, pas de bol, si elles peuvent survenir, elles surviendront forcément, et de préférence au pire moment qui soit.

Les exemples classiques de ce genre de situation sont (de manière non exhaustive):

• l'utilisateur qui supprime ou qui modifie un fichier ou un élément dans la base de données sans s'être assuré de maintenir la cohérence des données
• le serveur distant basé à Singapour ou à Orlando qui plante pour une raison inconnue
• une dépendance (non fournie par le programme) inexistante sur le système
• une connexion internet qui plante juste au moment où l'on veut se connecter à un serveur distant
• un périphérique quelconque inaccessible pour une raison ou une autre lorsqu'on veut l'utiliser
• une réponse négative de la part du seveur auquel on a envoyé une requète
• ...

A priori, la fonction qui rencontre ce genre de problème n'a absolument aucune autorité pour essayer de le résoudre. Mais, comme elle est dans l'incapacité de continuer le traitement qu'elle est occupée à faire, vu qu'elle ne peut disposer des données dont elle a besoin, la meilleure chose à faire est encore... de sortir de ce traitement qui ne mènera à rien.

Par la suite, il y a deux solutions:

• soit l'une des fonctions qui a mené à l'appel de cette fonction est en mesure de résoudre le problème (en essayant de contacter le serveur "plus tard", ou en essayant de récupérer une "sauvegarde" des informations), et "on est sauvé": le processus peut reprendre, et la fonction qui a rencontré le problème ne devrait plus le rencontrer.
• soit, on n'arrive pas à corriger le problème, et, comme nous ne pourrons de toutes manières pas avoir les données dont on a besoin, on n'a pas d'autre choix que de ... "laisser mourir" l'application de sa "belle mort".

L'idée n'est donc pas de ne pas essayer de résoudre les problèmes, mais d'essayer de le faire "quelque part" où ... nous serons en mesure (et où il fera sens) de le faire

[Médinoc]

Autre chose, il n'est pas "safe" de lancer et attraper des exceptions de, vers et même à travers une DLL ne venant pas du même compilo. Si une DLL compilée sous MinGW (gcc) appelle une DLL Win32 qui crashe, il y a des chances que les clauses catch et les destructeurs de la DLL MinGW ne soit pas exécutés (d'ailleurs même sous Visual, selon les paramètres de gestion des exceptions spécifiés au compilateur, ça peut ne pas marcher).

When you transfer control across stack frames, all the frames in between need to be in on the joke.

bacelar, est-il à la portée de tous d'utiliser Windows Error Reporting? Combien la société Microsoft facture-t-elle aux développeurs pour leur forwarder les rapports de plantage?

[alassanediakite]

Salut
koala01, je ne suis pas contre le fait qu'il faut laisser mourir l'appli. Mais pourquoi d'autres s'opposent farouchement à une deuxième option? c'est à dire signaler un problème inconnu et laisser l'appli tourner.
Prenons le cas d'un guichet avec un appli répondant à plusieurs services pour le client.
Une erreur inconnue survient pour un service pour un client. Faut-il ...

• réinitialiser l'appli avec tout le temps que cela prendra?
• ou afficher une erreur à l’opérateur qui informera tout de suite le service informatique tout en continuant à rendre d'autres services?

Question: est-ce ce type de débat entre linux et windows sur "l'écran bleu de windows"?
@+

[Médinoc]

Le problème, c'est qu'après une erreur qui montre une corruption du statut de l’application, laisser celle-ci tourner risque de propager les erreurs et corrompre d'autres parties... y compris les enregistrements.

Imagine que tu travailles sur un important document Word. Si un plug-in ajouté dans Word crashe, que préfères-tu:

• Word crashe immédiatement avec un message d'erreur que tu ne comprends pas.
• Word affiche un message d'erreur que tu ne comprends pas. Puis il semble continuer normalement, mais la prochaine fois que tu ouvres le document, il ne contient plus rien de lisible!

[alassanediakite]

Salut

Le problème, c'est qu'après une erreur qui montre une corruption du statut de l’application, laisser celle-ci tourner risque de propager les erreurs et corrompre d'autres parties... y compris les enregistrements.

Dans le cas que j'ai signalé, je suis "sûr" que le SGBD protégera mes données.

Imagine que tu travailles sur un important document Word. Si un plug-in ajouté dans Word crashe, que préfères-tu:

• Word crashe immédiatement avec un message d'erreur que tu ne comprends pas.
• Word affiche un message d'erreur que tu ne comprends pas. Puis il semble continuer normalement, mais la prochaine fois que tu ouvres le document, il ne contient plus rien de lisible!

Si vous n'avez pas de sauvegarde pour un important document Word aucune excuse ne peut vous être accordée. Cf Un développeur efface par erreur trois mois de travail avec Visual Studio Code 1.15
@+

[bacelar]

bacelar, est-il à la portée de tous d'utiliser Windows Error Reporting? Combien la société Microsoft facture-t-elle aux développeurs pour leur forwarder les rapports de plantage?

Pas grand-chose par rapport à un support international 24h/24 7j/7.
Sinon, on peut bricoler l'équivalent avec un simple watchdog.

Mais pourquoi d'autres s'opposent farouchement à une deuxième option? c'est à dire signaler un problème inconnu et laisser l'appli tourner.

Je pense qu'on a déjà pas mal illustré le fait que c'est aller droit dans le mur.

Une erreur inconnue survient pour un service pour un client. Faut-il ...
réinitialiser l'appli avec tout le temps que cela prendra?

Si vous avez fait correctement votre travail (caches, point de synchronisation, etc...), le redémarrage est rapide.

Question: est-ce ce type de débat entre linux et windows sur "l'écran bleu de windows"?

Le rapport ???

Dans le cas que j'ai signalé, je suis "sûr" que le SGBD protégera mes données.

Aucunement, votre application "boguée/plantée" a les mes pouvoirs que votre application avant le problème.

Si vous n'avez pas de sauvegarde pour un important document Word aucune excuse ne peut vous être accordée.

L'importance, elle est variable avec le temps.

Vérifiez les paramètres et les entrées utilisateurs, et les moutons seront bien gardés.

[koala01]

Dans le cas que j'ai signalé, je suis "sûr" que le SGBD protégera mes données.

Et comment peux tu en être "sur"

Si la requête d'ajout / de mise a jour est correctement formulée, il n'y a absolument aucun mécanisme qui permette à SQL de refuser l'ajout ou la modification de donnée.

Et le pire de l'histoire, c'est que tu peux très bien te retrouver avec des données qui semblent tout à fait cohérentes, mais qui ne le sont pas...

Et ce n'est que, peut-être plusieurs mois après l'incident, que l'on se rend compte que ces données corrompues ont propagé des informations erronées qui ont fini par véroler l'ensemble du système

Si vous n'avez pas de sauvegarde pour un important document Word aucune excuse ne peut vous être accordée.

Oui, mais bon, il y en a encore qui travaillent "sans filet"

Et puis, si ce n'était que le problème d'un document...

Mais, imagine un programme de simulation, qui doit travailler pendant 7heures 30 pour fournir un résultat complet (et cela existe) . En gros, le chercheur peut lancer deux simulations sur sa journées: une au matin, une autre au soir. Et il a tout juste le temps de modifier les paramètres, avant de devoir lancer la simulation "matinale" (autrement, il est bon pour les heures supp, histoire d'attendre la fin de la simulation).

Une donnée corrompue (pour n'importe quelle raison) va littéralement foutre en l'air l'ensemble de la simulation, car le résultat peut sembler cohérent, mais il sera aussi farfelu que les données sur lesquelles il est basé...

Laisser mourir le programme, si tu n'as pas les moyens de récupérer l'erreur, est toujours la meilleure chose à faire, parce que, sinon, dieu seul sait ce qui peut résulter de cette erreur

Salut
koala01, je ne suis pas contre le fait qu'il faut laisser mourir l'appli. Mais pourquoi d'autres s'opposent farouchement à une deuxième option? c'est à dire signaler un problème inconnu et laisser l'appli tourner.
Prenons le cas d'un guichet avec un appli répondant à plusieurs services pour le client.
Une erreur inconnue survient pour un service pour un client. Faut-il ...

• réinitialiser l'appli avec tout le temps que cela prendra?
• ou afficher une erreur à l’opérateur qui informera tout de suite le service informatique tout en continuant à rendre d'autres services?

@+

Si les services sont indépendants, et que tu peux te permettre de "désactiver" le service qui pose problème, fait le... Mais, ton appli tournera "sur trois pattes", tu ne crois pas

Maintenant, si -- comme c'est souvent le cas -- les différents services sont interconnectés, et que le service qui pose problème empêche (du seul fait du problème posé) les autres services de fonctionner, quel autre choix auras-tu que de dire "désolé, mais le service <machin> est indisponible, et ca m'empêche de faire quoi que ce soit d'autre"...

En plus, imagine l'opérateur qui doit dire "ah, désolé, mais ce service là ne fonctionne justement pas"... C'est lui (et non l'application ou son développeur) qui passe pour un con

[alassanediakite]

Salut
La leçon est très bien comprise. Je tacherai dorénavant de faire le meilleur choix.
Pour...

En plus, imagine l'opérateur qui doit dire "ah, désolé, mais ce service là ne fonctionne justement pas"... C'est lui (et non l'application ou son développeur) qui passe pour un con

on est fréquemment confronté à ces genres de problèmes et on a toujours compris que l'opérateur n'y est pour rien et ils ont très souvent la bonne manière pour repondre.
Merci à vous et @+