Discussion :

[Captain'Flam]

Bonjour à toutes & tous,

Il y a des exceptions que l'on ne peut pas rattraper :

Par exemple, même un try / catch (...) ne peut rattraper une division par zero ou un accès à une adresse invalide (déréférencement d'un pointeur nul).

D'où ma question : y a-t-il une norme qui définisse les erreurs non "catchables" ?

Merci !

[ternel]

A priori, en dehors d'un throw que tu codes toi-même, tu ne peux avoir d'exception que par un appel de fonction, et si celle-ci est proprement codée.
Tout le reste, si c'est susceptible de planter, le fera violemment.

Tu ne peux catcher que ce qui est throwé.
Vu autrement, ce qui n'est pas throwé n'est pas une exception.

Ca laisse de la place: toutes les "undefined behaviour", et éventuellement une partie des "unspecified behaviour".

Je pense que tu peux avoir une sorte de liste en cherchant toutes les occurences des ces deux expressions dans la norme.
Par exemple, il y a accéder à un itérateur invalidé, ou à un end() de n'importe quel conteneur

[bacelar]

Alors, je vais commencer par un sermon : on n'écrit JAMAIS "try / catch (...) ", JAMAIS, JAMAIS , ...

On ne catch que les exceptions que l'on sait traiter.


Le CPU est capable de "thrower" tout et n'importe quoi et n'importe où.
Le compilateur lui, il ne peut/beut pas tout faire.

Chaque compilateur dispose d'une panoplie de flags pour customiser la politique de gestion des exceptions (traitement du lancement d'exception "numérique" venant du code à la C, gestion asynchrone des exceptions, etc...)

Faut potasser la documentation du compilateur, et préparer un tube d'aspirine.

[Médinoc]

Sous Windows, la division par zéro est une exception Win32, catchable par __try {} __except(filtre) { } au lieu de try/catch.

[ternel]

C'est bien ce que dit bacelar: un tube d'aspirine

[bacelar]

Alors, pour la division par zéro, on peut faire une petite moulinette qui converti les exception SEH en exceptions C++:
_set_se_translator
https://msdn.microsoft.com/fr-fr/library/5z4bw5h5.aspx

Mais bon

[ternel]

Et puis, on adore le coté parfaitement standard de cette approche

[koala01]

Salut,

Et surtout, on "blinde" la fonction qui s'occupe de la division. Dans le meilleur des cas, une assertion suffit si l'on sait que l'application sera développée de manière à s'assurer que le diviseur n'est pas différent de 0 (comprend : si on sait que la programmation par contrat sera suffisante):

Code :

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

1
2
3
type foo(type dividende, type diviseur){
    assert(diviseur != 0);
}

Dans le pire des cas, on passe en mode "programmation défensive" et on s'arrange pour lancer notre propre exception avant que la division par zéro ne survienne :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
class ZeroDivisonError : public std::domain_error{
public:
    ZeroDivisonError(): std::domain_error("cannot divide by zero");
};
type foo(type dividende, type diviseur){
    if(diviseur == 0)
        throw ZeroDivisionError;
    /* ... */
}

NOTA : j'ai choisi de faire hériter mon exception de std::domain_error car il s'agit d'une erreur de logique spécifique au domaine de la division. std::domain_error héritant de manière indirecte de std::exception, elle pourra être récupérée au choix par un catch(std::exception & e) ou par un catch beaucoup plus précis ( catch (ZeroDivisionError & e)) voir par tout catch destiné à récupérer les exceptions intermédiaire (std::logical_error et std::domain_error).