C++ : Rattraper une erreur de division par zéro

Ici est un simple morceau de code où une division par zéro se produit. Je suis en train d'essayer de l'attraper :

#include <iostream>

int main(int argc, char *argv[]) {
    int Dividend = 10;
    int Divisor = 0;

    try {
        std::cout << Dividend / Divisor;
    } catch(...) {
        std::cout << "Error.";
    }
    return 0;
}

Mais l'application se bloque de toute façon (même si j'ai mis l'option -fexceptions de MinGW).

Est-il possible de prendre une telle exception (que je comprends, c'est pas une des exceptions C++, mais un FPU exception) ?

Je suis conscient que je pourrais consulter pour le diviseur avant la division, mais j'ai fait l'hypothèse que, parce qu'une division par zéro est rare (au moins dans mon application), il serait plus efficace d'essayer de la division (et la capture de l'erreur si elle se produit) que de tester à chaque fois le diviseur avant de se diviser.

Je suis en train de faire ces tests sur un WindowsXP ordinateur, mais vous souhaiteriez en faire de la croix-plate-forme.

if (Divisor == 0) { std::cout << "Error."; exit; }. Vous ensuite d'éliminer toute cause de ce qui se passe. Ensuite, vous pouvez supprimer le conditionnel et l'expédition de votre produit avec pas de division par des zéros.
(Un assert(Divisor != 0) serait plus canonique. N'oubliez pas de développer en cours d'exécution à travers un débogueur!)
Ce n'est même pas un FPU exception, mais le CPU exception. FPU poignées de nombres à virgule flottante, mais vous obtiendrez NaN ou l'infini, avec elle, pas un plantage.
Règle de base: TOUJOURS (et dans le cas où vous avez manqué l'accent: TOUJOURS!) vérifiez vos informations avant de faire les calculs et vous éviter ces types de problèmes.
"J'ai fait l'hypothèse que, parce qu'une division par zéro est rare (au moins dans mon application), il serait plus efficace" - alors il ne faut pas faire de telles hypothèses avant d'exécuter le générateur de profils. Faire des hypothèses sur le bleu est une façon d'échouer lors de l'optimisation. Faites confiance à votre optimiseur et votre CPU de la direction de la prévision.
Java n'a pas de problème: ideone.com/Ro5mw3. C'est probablement les tests à chaque diviseur avant de passer à la CPU.

InformationsquelleAutor Jérôme | 2011-01-20

c++exception-handling mingw performance

32

Ce n'est pas une exception. C'est un erreur qui est déterminé à matériel niveau et est retournée au système d'exploitation, qui en informe ensuite votre programme dans certains OS de manière spécifique à ce sujet (comme, par tuer le processus).

Je croire que, dans de tels cas, ce qui se passe n'est pas une exception, mais un signal. Si c'est le cas: Le système d'exploitation interrompt votre principal du programme de contrôle de débit et les appels d'un gestionnaire de signal, qui - à son tour - arrête le fonctionnement de votre programme.

C'est le même type d'erreur qui s'affiche lorsque vous déréférencement d'un pointeur null (puis votre programme se bloque par signal SIGSEGV, segmentation fault).

Vous pouvez essayer d'utiliser les fonctions de <csignal> - tête pour essayer de donner un gestionnaire personnalisé pour le signal SIGFPE (c'est pour virgule flottante exceptions, mais c'est peut être le cas, elle est également soulevée pour la division entière par zéro - je suis vraiment pas sûr ici). Vous devez cependant noter que le traitement du signal est OS-dépendante et MinGW en quelque sorte "émule" les signaux POSIX sous l'environnement Windows.

Voici le test sur MinGW 4.5, Windows 7:
```
#include <csignal>
#include <iostream>

using namespace std;

void handler(int a) {
    cout << "Signal " << a << " here!" << endl;
}

int main() {
    signal(SIGFPE, handler);
    int a = 1/0;
}
```
De sortie:

Signal 8 ici!

Et à droite après l'exécution du gestionnaire de signal, le système tue le processus et affiche un message d'erreur.

En utilisant cela, vous pouvez fermer toutes les ressources de journal ou un message d'erreur après une division par zéro ou un déréférencement de pointeur null... mais contrairement aux exceptions qui n'est PAS un moyen pour contrôler votre programme de flux, même dans des cas exceptionnels. Un programme ne devrait pas le faire. La capture de ces signaux n'est utile pour le débogage/diagnostic fins.

(Il y a certains signaux qui sont très utiles en général dans la programmation de bas niveau et ne causent pas de votre programme pour être tué tout de suite après le gestionnaire, mais c'est un profond sujet).
- Windows dispose d'un cadre agréable exception basée sur des installations de manutention (et probablement le C++ cadre d'exception est construit sur l'installation de Windows). Il est possible par l'intermédiaire d'un commutateur de compilateur pour transformer matériel exceptions en C++ exceptions, si vous avez besoin de prendre soin - sur-zélés de la gestion des pannes pouvez-vous obtenir dans indéfini unis. (Remarque, en passant, je persiste dans l'appel de division par zéro, avec une exception: l'OS et le matériel vous confirmer que c'est une exception, il est tout simplement pas une des exceptions C++). MODIFIÉ: oups, oublié le MinGW partie de la question. Que probable change beaucoup de choses. Je vais laisser ma langue de bois ici de toute façon.
- Pouvez vous s'il vous plaît ajoutez de la bonne référence pour les signaux (en particulier ceux à ne pas tuer les processus)?
- C'est OS. POSIX définit ces; Windows n'est pas POSIX-compilant mais MinGW fait de son mieux pour combler le fossé un peu. Pour Linux, vous avez cette page, commune des exemples de "non-létale" singals sont SIGSTOP, SIGTSTP (arrêt temporaire) et son état (continuer).
- Même les gens ne sont pas limités par la norme POSIX et sont donc en mesure d'attraper les exceptions à l'aide d'un bloc catch. Voyons combien d'années encore faudra, jusqu'à ce que la fonctionnalité dans LINUX. L'option de correspondance (-fnon-appel-exceptions) est déjà disponible, mais prévu pour les pommes OS.
InformationsquelleAutor Kos
13

La division par zéro est une erreur de logique, un bug par le programmeur. Vous ne devriez pas essayer d'y faire face, vous devez déboguer et de l'éliminer. En outre, la capture des exceptions est extrêmement coûteux - de façon plus que diviseur vérification sera.

Vous pouvez utiliser la gestion Structurée des exceptions pour rattraper l'erreur de division par zéro. Comment c'est réalisé dépend de votre compilateur. MSVC propose une fonction pour récupérer Structurée des Exceptions comme catch(...) et fournit également une fonction de traduire Structurée des Exceptions dans les exceptions, ainsi que l'offre __try/__except/__finally. Cependant, je ne suis pas assez familier avec MinGW pour vous dire comment le faire dans ce compilateur.
- +1 pour les conseils de réparer le trou dans le mur, plutôt que d'essayer d'accrocher un tableau sur elle.
- -1 pour la surutilisation de métaphores.
- +1 pour dire que la vérification d'une condition est moins cher que l'interception d'une exception.
- Euh, l'abus de métaphores? Je ne vois pas de métaphores.
- la vérification est seulement moins cher que une exception pour les très trivial code
- Pas toujours vrai - envisager le calcul scientifique, où 0.0, en général, a une certaine limite, mais peu de probabilité de se produire.
- float a=1, b=0, c; c=a/b; est valide #inf et float a=0, b=0, c; c=a/b; est valide #nan qui peuvent être testés. Aussi, il est possible de vérifier si(b==0) plan de sauvetage();
- Je ne suis pas d'accord pour dire que "la division par zéro==programmeur bug". L'imagerie d'exécuter un algorithme complexe sur un tas d'aléas et de données d'entrée(données de la source externe, fichier du disque, réseau, etc), ce qui pourrait éventuellement causer une division par zéro, alors vous réalisez la vérification de zéro avant chaque utilisation de / opérateur est très lourd. Puis, quelque chose comme Windows SEH est un bon secours.
InformationsquelleAutor Puppy
8
1. Il n'y a n'est pas un
  la langue standard manière de capter l'
  la division par zéro de la CPU.
2. Ne pas prématurément "optimiser" l'écart d'un
  de la branche. Votre demande est
  vraiment le CPU dans ce contexte? J'en doute, et il n'est pas vraiment un
  optimisation si vous cassez votre code.
  Sinon, je pourrais faire de votre code
  encore plus rapide:
```
int main(int argc, char *argv[]) { /* Fastest program ever! */ }
```
InformationsquelleAutor Greg D
6

Division par zéro n'est pas une exception en C++, voir https://web.archive.org/web/20121227152410/http://www.jdl.co.uk/briefings/divByZeroInCpp.html
- L'OP a dit que, dans la question. "Est-il possible de prendre une telle exception (que je comprends, c'est pas une des exceptions C++, mais un FPU exception)?"
- L'OP devrait juste faire un zéro vérifier 🙂
- mais il devrait être une exception
InformationsquelleAutor ismail
3

En quelque sorte la véritable explication est toujours manquant.

Est-il possible de prendre une telle exception (que je comprends, c'est pas une des exceptions C++, mais un FPU exception) ?

Oui, votre catch bloc devrait fonctionner sur certains compilateurs. Mais le problème est que vos exception n'est pas de FPU exception. Vous faites division entière. Je ne sais pas si c'est aussi un catchable d'erreur, mais il n'est pas de FPU exception, qui utilise une fonctionnalité de l'IEEE sur la représentation des nombres en virgule flottante.
- Pire: c'est UB.
- La FPU, les exceptions ne sont pas pris en catch(...) dans la norme C++. Mais au moins un compilateur a soutenu, il y a longtemps. À savoir, Visual C++ une fois avait que comme une extension du langage. Je crois, me souviens, que l'extension était présent dans la version 6.0, qui a été pré-norme, et a été abandonné dans la version 7.0, le premier Visuel Studio.NET version et post C++98.
InformationsquelleAutor Konrad Rudolph

Sur Windows (Visual C++), essayez ceci:

BOOL SafeDiv(INT32 dividend, INT32 divisor, INT32 *pResult)
{
    __try 
    { 
        *pResult = dividend / divisor; 
    } 
    __except(GetExceptionCode() == EXCEPTION_INT_DIVIDE_BY_ZERO ? 
             EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH)
    { 
        return FALSE;
    }
    return TRUE;
}

MSDN: http://msdn.microsoft.com/en-us/library/ms681409(v=vs. 85).aspx

pas besoin d'utiliser cette ancienne try-catch mais normal C++ try-catch avec (...) est aussi de le faire, en supposant que l'option de compilateur /EHa est utilisé.

InformationsquelleAutor jalal sadeghi

0

Bien, si il y a une exception de manutention à ce sujet, quelques élément nécessaires pour faire le vérifier. Par conséquent, vous ne perdez rien si vous le vérifier vous-même. Et il n'y a pas beaucoup qui est plus rapide qu'une simple comparaison de résultats (une seule CPU "d'instruction saut si égal à zéro" ou quelque chose comme ça, ne me souviens pas le nom)

InformationsquelleAutor Atmocreations

Pour éviter infini "Signal 8 ici!" les messages, il suffit d'ajouter "quitter" pour Kos nice code:

#include <csignal>
#include <iostream>
#include <cstdlib> //exit

using namespace std;

void handler(int a) {
    cout << "Signal " << a << " here!" << endl;
    exit(1);
}

int main() {
    signal(SIGFPE, handler);
    int a = 1/0;
}

InformationsquelleAutor nibrot

-1

Comme les autres ont dit, ce n'est pas une exception, il génère simplement un NaN ou Inf.

Zéro fracture n'est qu'un moyen de le faire. Si vous faites beaucoup de maths, il y a beaucoup de façons, comme

log(not_positive_number), exp(big_number), etc.

Si vous pouvez vérifier la validité des arguments avant de faire le calcul, puis le faire, mais parfois, c'est dur à faire, alors vous pouvez avoir besoin de générer et de gérer une exception.

Dans MSVC il y a un fichier d'en-tête #include <float.h> contenant une fonction _finite(x) qui indique si un nombre est fini.
Je suis sûr que MinGW a quelque chose de similaire.
Vous pouvez tester que, après un calcul et lancer/attraper votre propre exception ou quoi que ce soit.
- Ce serait vrai pour les chars, mais cet exemple est avec des entiers, donc pas de NaN et aucune inf, le PROCESSEUR génère un signal/structured exception/tout ce que vous voulez l'appeler à la place.
- Touche'. BTW, n'est-ce pas argumenter avec vous pendant un certain temps. Espérons que les choses sont bien.
InformationsquelleAutor Mike Dunlavey

Vous devez vous connecter pour publier un commentaire.