Exception non intercept�e

Version imprimable

Bonjour,

J'ai ceci et l'exception g�n�r�e "TEST" n'est pas intercept�e et je ne comprends pas pourquoi. Vos lumi�res seraient le bienvenues.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
   class Exception : public std::exception
   {
      public :
      std::string Message;
      explicit Exception(std::string const& Mes) throw() : Message(Mes) { }
      explicit Exception(const char *Mes) throw()          : Message(Mes) { }
      virtual const char* what() const throw()       {   return(exception::what());   }
      virtual ~Exception() throw() { }
   };
 
   int main() {
     try {
       throw std::logic_error("TEST");   // n'est pas interceptée dans le catch
       throw Exception("TEST2");  // est bien interceptée dans le catch
    } catch (Exception &e) {
      printf("%s\n",e.massage.c_str();
      retrun(1);
    }
    retrun(0);
  }

28/03/2022, 12h30
dalfab

Bonjour,

std::logic_error est une std::exception, elle peut �tre intercept�e par catch ( std::logic_error& ) ou catch ( std::exception& ) ou aussi catch ( std::logic_error ) ou catch ( ... ).
Mais std::logic_error n'est pas une Exception.
28/03/2022, 13h26
uriotcea

Bonjour,

merci de ta r�ponse rapide, mais je ne comprends pas ma class Exception h�rite de std::exception !
Alors peut-�tre que mes comp�tences en C++ sont trop limit�es, mais alors comment puis-je cr�er une clase d'exception interceptant mes propres Exception et std::exception, enfin TEST et TEST2 ?
28/03/2022, 14h13
Bousk

Tu dis toi-m�me que ton Exception h�rite de std::exception, et n'est donc pas une std::logic_error.
Donc forc�ment si tu throw une std::logic_error, ben tu peux pas l'attrapper dans une Exception. Ni l'inverse.

pourtant le code suivant intercepte bien l'exception en question:

Code:

1
2
3
4
5
6
 
try {
   throw std::logic_error("TEST");   // n'est pas interceptée dans le catch
} catch (std::exception &e) {
    printf("%s\n",e.what());
 }

28/03/2022, 14h55
Bousk

Oui parce que std::logic_error h�rite de std::exception et en tant que tel la relation entre elles est "est un". Une std::logic_error est une std::exception.
Ton Exception n'est pas une std::logic_error. :weird:
28/03/2022, 14h56
jo_link_noir

std::logic_error h�rite de std::exception (comme toutes les exceptions du standard).

Par cons�quent, std::logic_error et Exception sont des std::exception, mais Exception n'est pas une std::logic_error et std::logic_error n'est pas Exception.
28/03/2022, 15h03
uriotcea

Ok je pige mieux, alors comment puis-je �crire ma propre class d'exception h�ritant de toute les exception standard, puis que je ne peux utiliser directement std::exception parque impossible de faire ma propre exception du style :
throw exception("TEST");
28/03/2022, 15h17
Bousk

Si tu veux intercepter toutes les exceptions standards, tu interceptes std::exception et pas std::logic_error ou ta classe Exception. :calim2:
28/03/2022, 15h44
uriotcea

On revient � ma question initiale, pourquoi ma class Exception n'intercepte pas les exe standards?:D:D
28/03/2022, 17h29
Bousk

Faut lire et comprendre ce qu'on �crit.

Citation:

Envoy� par Bousk

Oui parce que std::logic_error h�rite de std::exception et en tant que tel la relation entre elles est "est un". Une std::logic_error est une std::exception.
Ton Exception n'est pas une std::logic_error. :weird:

Parce que ta classe Exception est une sp�cialisation d'un type d'exception standard donc non tu ne peux pas intercepter toutes les exceptions standards avec Exception vu que toutes les exceptions standards ne sont pas des Exceptions.
C'est un peu le niveau 0 de la hi�rarchie de classe, de l'h�ritage et la relation est-un.

Si je te donne un rectangle de c�t�s A et B et un carr� de c�t� A, tu pourrais mettre le carr� dans la forme rectangulaire, le carr� �tant un rectangle particulier dans ce cas.
Ta classe Exception est un cercle, �a n'a juste rien � voir.
28/03/2022, 19h20
uriotcea

Ok, c'est plus clair, d�sol� si je ne suis pas tr�s � l'aise avec ces notions. Alors comment puis je cr�e ma class h�ritant de toutes ces exceptions ? H�ritages multiples ?
29/03/2022, 01h39
jo_link_noir

Visiblement tu ne comprends toujours pas comment fonctionne l'h�ritage.

Quel probl�me essayes-tu de r�soudre et pourquoi catcher std::exception n'est pas suffisant ?

Salut,

Pour te permettre de comprendre, un petit sch�ma semble s'imposer. D�sol�, mais il va prendre la forme d'un dessin en ASCII ART ;)

Voici la situation dans laquelle tu es:
Code:

1 2 3 4 5 6 classe de base std::exception / \ hérite: toutes les classes de / \ la deuxième ligne sont des std::exception défini comme tel par la SL <-- / \ -->défini comme tel par toi / \ std::logical_error Exception
(normalement, dans un sch�ma UML, il devrait y avoir une fl�che en triangle pointant vers std::exception, malheureusement, les limites de l'ASCII ART ne me permettent pas de la repr�senter ;) )
Cela implique:
que la classe std::logical_error EST-UN(e) std::exception
que ta classe Exception EST-UN(e) std::exception

Or, il faut l'admettre, la notion d'h�ritage est tr�s mal desservie par cette expression "EST-UN(e)" car elle a beau �tre "simple � retenir", elle laisse croire que la relation d'h�ritage pourrait s'appliquer entre un carr� et un rectangle sous pr�texte que l'on a tous appris � l'�cole ... qu'un carr� EST-UN rectangle (ayant quatre cot� �gaux / deux diagonales perpendiculaires).

Or il se fait que le carr� n'est -- �ventuellement -- qu'un "�tat tr�s particulier" du rectangle qui n�cessiterait "simplement" d'avoir une fonction membre estCarre renvoyant true si les quatre c�t�s du rectangle sont �gaux.

Car le fait est que la notion d'h�ritage est dirig�e par le principe de base connue sous l'acronyme LSP (pour Liskov Substitution Principle ou principe de substitution de Liskov).

Si cela t'int�resse, je t'expliquerai pourquoi il est impossible d'envisager l'h�ritage entre un carr� et un rectangle � cause de ce principe. Seulement, comme je pr�vois d�j� de faire une r�ponse beaucoup trop longue, je pr�f�re attendre que tu en fasse la demande :D

Donc, pour en revenir � nos moutons, l'expression qu'il "serait pas mal d'utiliser" (dans un monde id�al) ressemble d'avantage �

Citation:

PEUT PASSER POUR ETRE UN

ou m�me, histoire de reprendre le mot le plus important que l'on trouve dans le nom du principe qui r�git l'h�ritage

Code:

PEUT ETRE SUSBSTITUE A UN(e)

Nous en arriverions donc avec cette expression � dire que

std::logical_error PEUT ETRE SUBSTITUEE A UNE std::exception (comprend: on peut transmettre une std::logical_error � tout ce qui s'attend � receevoir une std::error)
ta classe Exception PEUT ETRE SUBSTITUEE A UNE std::exception (comprend: on peut transmettre un objet du type de ton Exception � tout ce qui s'attend � receevoir une std::error)

Apr�s avoir exprim� les choses sous cette forme (qui est quand m�me beaucoup plus correcte et cens�e :D ), il nous "suffira" d'ouvrir un peu les yeux pour nous rendre compte qu'il n'y a aucun lien direct entre la classe std::logical_error et ta classe Exception.

Et surtout de nous rappeler que la notion d'h�ritage est "� sens unique" vu qu'il y a toujours une classe "de base" (ou "parent") et une classe "d�riv�e" (ou "enfant") et qu'il est g�n�ralement impossible d'inverser les deux.

Si bien qu'il est tout � fait juste de dire, aussi bien pour std::logic_error que pour ta classe Exception qu'elles sont toutes les deux "suceptibles de passer pour �tre une std::exception" mais que l'on ne peut pas dire en retour que std::exception soit ... susceptible de passer pour �tre une std::logical_error ou ta classe Exception.

H� bien, dans le catch, il faut suivre la m�me logique:

Ou bien tu r�cup�re toutes les exceptions qui sont "susceptibles de passer pour �tre une std::exception", c'est � dire la classe std::exception (forc�ment :D) ainsi queta classe Exception et la classe std::logical_error ainsi que toutes les autres classes d'exceptions (qui d�rivent toutes de mani�re directe ou indirecte de std::exception) et toutes les classes d�rivant (de mani�re directe ou indirecte) de std::exception qui trainent dans ton projet (et dans tes biblioth�ques tierces)
Ou bien tu r�cup�re sp�cifiquement std::logic_error, ainsi que les classes qui en d�rivent (de mani�re directe ou indirecte) qui "trainent" dans ton projet et dans les biblioth�ques tierces (mais aucune des classes parentes std::logic_error)
Ou bien tu r�cup�re sp�cifiquement ta classe Exception, ainsi que les classes qui en d�rivent (de mani�re directe ou indirecte) qui "trainent" dans ton projet (mais aucune des classes parentes de ta classe Exception)

Et donc, si tu ne veux pas r�cup�rer les std::logic_error ET ta classe Exception (ainsi que toutes les classes qui en d�rivent de mani�re directe ou indirecte) mais que tu "te fous pas mal" de toutes les exceptions fournies par la biblioth�que standard qui ne sont pas sp�cifiquement std::logic_error, ben, tu n'a pas d'autre choix que de le faire en deux fois:
un catch r�cup�re std::logic_error (et tout ce qui en d�rive)
un autre catch r�cup�re Exception (et tout ce qui en d�rive)

Tu peux, bien sur, les mettre au m�me endroit dans ton code, par exemple sous une forme proche de
Code:

1 2 3 4 5 6 7 8 9 10 try{ maybeThrowLogicError(); maybeThrowException(); } catch(Exception & e){ // L'ordre n'a aucune espèce d'importance // ... } catch(std::logic_error & e){ // ... }
Mais tu peux aussi les mettre � des endroits ou � des niveaux diff�rents, sous une forme qui serait alors proche de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 void maybeFail(){ // un point particulier où les deux cas de figure peuvent survenir maybeThrowLogicError(); maybeThrowException(); } void whatIfLogicError(){ try{ mayBeFail(); }catch(std::logic_error &e){ // on traite en priorité la logique (ca aurait pu être l'inverse :D) } } void whatIfAnyError(){ try{ whatIfLogicError();// la logique est traitée ici, plus besoin de s'en inquiéter }catch(Exception &e){ // on traite ce qui relève de Exception uniquement ici } }
Et, bien sur, tu auras compris que l'on peut complexifier les choses � loisir, en d�cidant -- pouruqoi pas, apr�s tout -- de traiter "une partie du probl�me" soulev� par le fait que "std::exception" a �t� lanc�e "dans la fonction qui a �t� appel�e par la fonction appel�e par la fonction machin qui a �t� appel�e par la fonction bidule", une autre partie "deux niveaux plus haut" dans la pile d'appels ainsi qu'une troisi�me partie encore trois niveaux plus haut et de faire pareil -- mais � des niveaux diff�rents -- lorsqu'une exception de type Exception est lanc�e, "tout simplement" parce que ce sont les endroits o� ces diff�rentes gestions ont le plus de sens.

Ce qu'il faut, finalement comprendre et retenir, c'est que le type de l'exception que tu attrapes avec catch sert de "filtre" �vitant qu'absolument tout ce qui ne peut pas se substituer au type indiqu� d'�tre pris en compte, et ce, m�me si le type indiqu� peut quant � lui se substituer � "un autre". Parce que ce n'est pas "cet autre type" que l'on veut g�rer, mais bien ... le type indiqu� ;)

EDIT: Allez, un dernier pour la route:

Notes que, si tu te dis que toutes les exceptions qui seront lanc�es d�rivent de mani�re directe ou indirecte de std::logic_error et que tu veux r�cup�rer en une seule fois les std::logic_error ET ta classe Exception (mais uniquement ces classes l�), rien en t'emp�che
de faire h�riter ta classe Exception de std::logic_error
rattraper toutes les exceptions "pouvant se substituer � une std::logique error (en ce, y compris ta propre classe d'excpetion) avec un catch (std::logic_error &e)Evidemment, cela sous-entend qu'il doit y avoir du sens � se dire que "ta classe Exception repr�sente une erreur particuli�re survenue � cause d'un probl�me de logique", vu que c'est la mani�re dont l'h�ritage aura pour r�sultat de la faire passer :$

29/03/2022, 09h59
uriotcea

Bonjour,

Alors l� bravo, j'appr�cie vraiment.
Que dire de plus � part, merci beaucoup pour cette longue et claire explication.