La capture d'exception: division par zéro

Mis à jour avec les commentaires de ExcessPhase

GCC (au moins la version 4.8) vous permettra d'émuler ce comportement:

#include <signal.h>
#include <memory>
#include <iostream>

int main() {
    std::shared_ptr<void(int)> handler(
        signal(SIGFPE, [](int signum) {throw std::logic_error("FPE"); }),
        [](__sighandler_t f) { signal(SIGFPE, f); });

    int i = 0;

    std::cin >> i;  //what if someone enters zero?

    try {
        i = 5/i;
    }
    catch (std::logic_error e) {
        std::cerr << e.what();
    }
}

Ce met en place un nouveau gestionnaire de signal qui déclenche une exception, et une shared_ptr à l'ancien gestionnaire de signal, avec une "suppression" fonction qui restaure l'ancien gestionnaire quand elle est hors de portée.

Vous avez besoin de compiler avec au moins une de ces options:

g++ -c Foo.cc -o Foo.o -fnon-call-exceptions -std=c++11

Visual C++ vous permettra aussi de faire quelque chose de similaire:

#include <eh.h>
#include <memory>

int main() {
    std::shared_ptr<void(unsigned, EXCEPTION_POINTERS*)> handler(
        _set_se_translator([](unsigned u, EXCEPTION_POINTERS* p) {
            switch(u) {
                case FLT_DIVIDE_BY_ZERO:
                case INT_DIVIDE_BY_ZERO:
                    throw std::logic_error("Divide by zero");
                    break;
                ...
                default:
                    throw std::logic_error("SEH exception");
            }
        }),
        [](_se_translator_function f) { _set_se_translator(f); });

    int i = 0;

    try {
        i = 5 / i;
    } catch(std::logic_error e) {
        std::cerr << e.what();
    }
}

Et bien sûr, vous pouvez ignorer tout le C++11-ishness de cette et les mettre dans un traditionnel RAII-gestion des struct.

Vous avez besoin de jeter l'exception manuellement à l'aide de throw mot-clé.

Exemple:

#include <iostream>
using namespace std;

double division(int a, int b)
{
   if( b == 0 )
   {
      throw "Division by zero condition!";
   }
   return (a/b);
}

int main ()
{
   int x = 50;
   int y = 0;
   double z = 0;

   try {
     z = division(x, y);
     cout << z << endl;
   }catch (const char* msg) {
     cerr << msg << endl;
   }

   return 0;
}

setjmp + longjmp

https://stackoverflow.com/a/25601100/895245 mentionné la possibilité ou jeter une des exceptions C++ à partir d'un gestionnaire de signal, mais La levée d'une exception à l'intérieur d'un gestionnaire de signal mentionne plusieurs mises en garde, donc je serais très prudent.

Comme un autre potentiellement dangereux possibilité, vous pouvez également essayer d'utiliser l'ancienne C setjmp + longjmp mécanisme, tel que montré à: C poignée de signal SIGFPE et de continuer l'exécution

#include <csetjmp>
#include <csignal>
#include <cstring>
#include <iostream>

jmp_buf fpe;

void handler(int signum) {
    longjmp(fpe, 1);
}

int main() {
    volatile int i, j;
    for(i = 0; i < 10; i++) {
        struct sigaction act;
        struct sigaction oldact;
        memset(&act, 0, sizeof(act));
        act.sa_handler = handler;
        act.sa_flags = SA_NODEFER | SA_NOMASK;
        sigaction(SIGFPE, &act, &oldact);
        if (0 == setjmp(fpe)) {
            std::cout << "before divide" << std::endl;
            j = i / 0;
            sigaction(SIGFPE, &oldact, &act);
        } else {
            std::cout << "after longjmp" << std::endl;
            sigaction(SIGFPE, &oldact, &act);
        }
    }
    return 0;
}

Compiler et exécuter:

g++ -ggdb3 -O0 -std=c++11 -Wall -Wextra -pedantic -o main.out main.cpp
./main.out

De sortie:

i = 0
before divide
after longjmp
i = 1
before divide
after longjmp
i = 2
before divide
after longjmp

man longjmp dit que vous pouvez longjmp de gestionnaires de signaux, mais avec quelques bémols:

POSIX.1-2008 date de Rectificatif Technique 2 ajoute longjmp() et siglongjmp() à la liste des async-signal-les fonctions de sécurité. Toutefois, la norme recommande d'éviter l'utilisation de ces fonctions de gestionnaires de signaux, et continue à point
que si ces fonctions sont appelées à partir d'un gestionnaire de signal, ce qui a arrêté un appel à une non-async-signal-fonction de sécurité (ou l'équivalent, tels que les étapes équivalent à la sortie(3) qui se produisent lors d'un retour de la première
appel à la main()), le comportement est indéfini si le programme a par la suite fait un appel à une non-async-signal-fonction de sécurité. La seule manière d'éviter un comportement indéfini est d'assurer l'une des opérations suivantes:

• Après saut en longueur à partir du gestionnaire de signal, le programme ne fait appel à toute non-async-signal-les fonctions de sécurité et n'a pas de retour de l'appel initial à main().

• Tout signal dont le gestionnaire effectue un saut en longueur doit être bloqué lors de chaque appel à une non-async-signal-fonction de sécurité et de non-async-signal-les fonctions de sécurité sont appelés après le retour de l'appel initial à main().

Voir aussi: Longjmp de gestionnaire de signal?

Cependant La levée d'une exception à l'intérieur d'un gestionnaire de signal mentionne que cela a plus de dangers avec C++:

setjmp et longjmp ne sont pas compatibles avec les exceptions et les RAII (ctors/dtors), si. 🙁 Vous aurez probablement des fuites de ressource avec cette.

de sorte que vous devez être très très prudent avec cela.

Je crois que la morale est que les gestionnaires de signaux sont durs, et vous devriez les éviter autant que possible, sauf si vous savez exactement ce que vous faites.

Détecter floating point zéro de la division

Il est également possible de détecter à virgule flottante de la division par zéro avec une glibc appel à:

#include <cfenv>

feenableexcept(FE_INVALID);

comme illustré à: Quelle est la différence entre le calme de NaN et de signalisation NaN?

De ce fait, il soulève SIGFPE ainsi comme la division entière par zéro au lieu de simplement en silence qnan et définissant des indicateurs.

Il vous suffit de faire assert(2 * i != i) qui lancera une assertion. Vous pouvez écrire votre propre classe d'exception si vous avez besoin de quelque chose de fantaisiste.