Discussion :

[Hibou57]

Les exceptions et leurs traitements
Quelles représentations pour les exceptions : classe ou identificateurs ?

Nul (ou Nil) ne sait si l’erreur de parcours dans le flot de contrôle d’un programme est l’exception qui confirme la règle, mais au moins chacun(e) est conscient(e) que l’exception doit être traité avec tout autant de sérieux que ce qui ne l’est pas.

J’invite ici chacun(e) à formuler son point de vue sur la question (vous en avez un, n’est-ce pas )

J’ouvre la danse en vous exposant une question que je me pose au sujet du traitement des exceptions en Pascal objet ou FreePascal, et surtout de l’aspect orienté objet du traitement des exceptions dans ces dialectes du Pascal.

J’ai un doute sur ce point précis. Les classes et les objets recouvrent deux aspects : un aspect « structure » et un aspect « polymorphisme ». L’aspect structure peut être accessible à la programmation structuré en générale, et si c’est des classes sont utilisé en Pascal pour le traitement des exception, l’intention initiale est certainement donc d’y amener le polymorphisme.

Mais dire que le polymorphisme est utile au traitement des exceptions, revient à prétendre que les classes peuvent encapsuler le traitement à la suite d’une exception (logique, puisque car on est dans un contexte polymorphisme+traitement-d’exception… alors que pourraient-elles encapsuler d’autre).

Mais d’un autre point de vue, la classe représentant l’exception étant défini par le code levant l’exception, et non pas le code traitant l’exception, cela amène le remarque que comme c’est le code levant l’exception, s’il encapsule un traitement d’exception dans les classes représentant les exceptions, alors ce code connaîtrait le traitement à faire suite à une exception.

Dans ce cas, encapsuler serait inutile, puisque le traitement pourrait être opérer immédiatement.

Je souligne cela pour dire que si encapsulation de traitement il y avait, il ne serait utile que du coté du code recevant l’exception (qui n’est pas toujours dans le même module, loin de là, et même pas toujours non-plus du/de-la même auteur). Mais cette encapsulation coté code receveur est impossible, sauf si le protocole d’émission des exceptions prévoyait que les codes receveur pouvaient initialisé (dans l’initialisation de l’application), les associations classes/exceptions. Mais cela ne fait pas parti du protocole (il n’y en a d’ailleur tout simplement pas du tout, de protocole)

Et si un tel protocole existait, fonctionnerait comme suit : les exception ne serait que des identificateurs, et les codes receveurs d’exception, associerait ces identificateurs à des classes. Mais dans le fond à ce point là, il n’y aurait même pas obligation d’associer les identificateurs à des classes, mais on pourrait les associers à n’importe quel autre traitement (programmation structuré standard).

Pour en revenir au point de départ, et faire un bilan sous l’éclairage de tout ceci : on remarquera (pour ce que j’en sais), que l’aspect polymorphisme n’est jamais utilisé dans le traitement des exception des programmes Pascal, et que l’utitlité des classes pour les exception n’y est donc jamais confirmer.

L’approche Ada (qui hérite directeemnt du Pascal), qui emploie de simple identificateur, me semble donc mieux réfléchi.

N.b. je ne cherche pas ici à discréditer le Pascal au pretexte de son traitement des exceptions, … loin de là… c’est au contraire pour mieux comprendre ou y voir plus clair. que j’appel à en discuter et à faire des commentaires sur ces remarques. Noter encore qu'il n'est pas obligatoire d'aboutir à la conclustion que l'approche Pascal des exception est vraiment bonne, tout comme il n'est pas obligatoire d'en arriver à la conclusion quelle est mauvaise.... mais il est sûrement bon d'argumenter les points de vues.

Bonne plume à tous/toutes

[Alcatîz]

Bonjour !

Pour en revenir au point de départ, et faire un bilan sous l’éclairage de tout ceci : on remarquera (pour ce que j’en sais), que l’aspect polymorphisme n’est jamais utilisé dans le traitement des exception des programmes Pascal, et que l’utitlité des classes pour les exception n’y est donc jamais confirmer.

Après trois aspirines et deux prozacs (il m'a bien fallu ça pour encaisser ton post ), j'ai consulté le source de l'unité SysUtils de Free Pascal et y vois tout-de-même une certaine utilité des classes :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Exception = class(TObject)
                    private
                      fmessage : string;
                      fhelpcontext : longint;
                    public
                      constructor create(const msg : string);
                      constructor createres(indent : longint);
                      property helpcontext : longint read fhelpcontext write fhelpcontext;
                      property message : string read fmessage write fmessage;
                  end;
ExceptClass = Class of Exception;
{ mathematical exceptions }
EIntError = class(Exception);
EDivByZero = class(EIntError);
ERangeError = class(EIntError);
EIntOverflow = class(EIntError);
EMathError = class(Exception);

[Hibou57]

Bonjour !

Après trois aspirines et deux prozacs (il m'a bien fallu ça pour encaisser ton post )

Oui, pardon... j'ai pas toujours la force de corriger toute les fautes de grammaire

j'ai consulté le source de l'unité SysUtils de Free Pascal et y vois tout-de-même une certaine utilité des classes

Je comprends ce que tu cite, mais.. mais...

Les propriétés de la classe Exception montrées ici, sont utilisé surtout pour le débugage, et/ou surtout aussi pour l'affichage des fameux « unhandled exception ». C'est de l'information passée par le code qui lève l'exception (et encore, une information qui n'est pas utile au traitement), et non pas une association faite entre l'exception et son traitement.

Là encore, le polymorphisme n'est d'aucune utilité pour traiter l'exception. Cela n'explique toujours pas pourquoi des classe, plutôt qu'un type simple. En Ada par exemple, exception est un type, un peu comme un type énuméré, mais qui peut être étendu, et les messages pour les « unhandled exception » sont directement générés par le compilateur, en employant le nom de l'exception.

J'ai l'impression que les classes sont ici utilisé non pas comme manière d'introduire les exceptions dans le langage, mais comme une manière de les implémenter pour les compilateurs.

Vraiment, je ne vois pas comment utiliser le polymorphisme pour traiter une exception, et il n'y a guère que l'identification de la classe qui sert à identifier l'exception... on pourrait tout aussi bien le faire avec un type énuméré (que l'on peut étendre).

Finalement une clause « on EDivError », est comme « if ClassOf (RaisedException) = EDivError ... » C'est tout, mais un type énuméré peut tout autant jouer le rôle de discriminant, et je dirais que les type énumérés sont même mieux venus pour cela (ils ne nécéssitent pas toute l'infrastructure rendue nécéssaire par les classes).

Mais peut-être que je m'exprime mal ou que j'ai mal fait comprendre ce que je voulais souligner.

En tous cas, merci pour ta réponse

P.S. Je pose surtout la question pour comprendre, parce que cela ne m'empêche pas d'utiliser les exceptions, ... même si ça me fait bizzare de produire des classes qui ne servent que de discriminant et à rien
d'autre .

P.P.S Le prozac ? T'es dure là quand-même ... me dire que ça t'a fait déprimer

[Alcatîz]

Oui, pardon... j'ai pas toujours la force de corriger toute les fautes de grammaire

P.P.S Le prozac ? T'es dure là quand-même ... me dire que ça t'a fait déprimer

Il s'agissait d'une boutade car la question est très pointue et nécessite plusieurs lectures.

Le traitement des exceptions par Free Pascal (ainsi que par Virtual Pascal) est un héritage direct de Delphi.
La question mériterait aussi d'être posée dans un cadre plus large que le langage Pascal.

[Hibou57]

Bonjour, je vois qu'on se sent bien ici même le dimanche

La question mériterait aussi d'être posée dans un cadre plus large que le langage Pascal.

Peut-être ici alors : Langages en général. Si tu as une idée, tu peux le déplacer une seconde fois.

Pour en revenir à la question, je n'avais pas tout dit hier.

Discriminant par catégorie plus générale

Une conscéquence possible de l'usage de classe dans ce contexte, pourrait être montré par cet exemple :

Code :

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

1
2
3
4
5
 
TYPE FileError = CLASS(Exception);
TYPE FileError1 = CLASS(FileError);
TYPE FileError2 = CLASS(FileError);
TYPE FileError3 = CLASS(FileError);

A ce moment là, on peut avoir

Code :

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

1
2
3
4
5
6
7
 
RAISE FileError2.Create('...');
.....
EXCEPT
   ON FileError1 ....
   ON FileError2 ....
END;

Mais si on ne peut pas traiter les erreurs avec autant de détails, alors on peut faire

Code :

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

1
2
3
4
5
6
 
RAISE FileError2.Create('...');
.....
EXCEPT
   ON FileError ....
END;

C'est à dire, qu'on peut traiter les erreurs par catégorie général.

Mais traiter les erreurs par catégorie générale, même si on peut en parler théoriquement, cela n'amène rien de concret.

Si on veut afficher un simple message d'erreur, traiter par catégorie n'apporte rien de plus.
Si on veut faire un véritablement traitement, on ne peut pas utiliser une catégorie générale comme discriminant, parce qu'on a besoind de connaitre précisement quelle erreur s'est produite.

Pour afficher un message d'erreur et arrêter la procédure en cours, à quoi peut bien servir un

Code :

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

1
2
3
4
5
6
 
RAISE FileError2.Create('...');
.....
EXCEPT
   ON FileError ....
END;

si c'est pour afficher un message « FileError2 s'est produite ».

Les catégories générales ne sont pas assez précises

Et si on veut traiter véritablement, et en admettant que FileError1 soit une erreur de fichier inexistant, et FileError2 une erreur de périphérique pendant l'accès au fichier (par exemple), alors à idem, savoir que c'est un FileError qui a été généré, ne permet aucun traitement, parce que cela recouvre des type d'erreur trop différent (si FileError1, alors on peut invité l'utilisateur/rice à redonner le chemin du fichier, et si FileError2, on peut retenter un certain nombre de fois, mais si on sait seulement que c'est FileError, on ne peut rien faire).

C'est encore une propriété des classe qui aurait put être mise en avant, mais qui apparaît finalement être inutile (dans l'état de ces arguments, sans plus).

Traiter une erreur sans aucun discriminant

Pour être exaustif, il existe une catégorie d'erreur qui peut être détecter également même sans utiliser les classes : c'est le fait qu'une erreur ait été levé, sans se soucier de laquelle il s'agit précisement.

Car que l'on représente l'exception avec un type énuméré ou une classe, on peut toujours avoir

Code :

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

1
2
3
4
5
6
 
RAISE FileError2.Create('...');
.....
EXCEPT
   ... netoyage ...
END;

un traitement qui ne se soucis pas de l'erreur précise, et qui fait seulement un netoyage en cas d'erreur en générale (c'est même le rois des traitements d'erreur, parce qu'au final, on voit quand même bien peu de traitement d'exception qui corrge véritablement une erreur... dans la vraie vie, on essaie surtout de limiter les dégats).

Et pour ça aussi, pas besoin de classe, les classes n'apporte rien, à par de la compléxité supplémentaire et inutile.

Les exceptions sont utiles aussi à la programmation procédurale simple

Encore une chose : la notion d'exception est utile même avec la programmation procédurale simple, et dire que les exceptions doivent êtres des classes, et affirmer que c'est dans leur nature, cela revient à dire que l'utilisation des exception est exclus de la programmation procédurale simple. Ce qui n'est pas vrai, bien sûre. Et je pense que cette exemple, si on s'en imprègne bien, et qu'on l'imagine bien, est celui qui démontre le mieux que les exceptions sont des instances d'un type simple, et non pas des classes (je vais me répeter, mais c'est encore une fois ce que fait Ada, qui déscend pourtant bien de Pascal, et qui ne renie pas le Pascal, loin de là... et qui connais pourtant aussi les objets, mais qui ne les appliquent pas aux exceptions).

Lever une exception ne devrait pas être risqué

En plus, je pense qu'un traitement d'erreur ne doit apporter aucune compléxité potentielle, et être représenter de manière aussi simple que possible : créer un objet pour lever une exception, s'est encourir le risque de produire une erreur pendant la levée d'une erreur... ce qui est quand même un comble. Avec un type simple, pas d'objet à créer, seulement une variable globale à instancier avec une constante (une variable visible ou cachée, peu importe), et aucun risque de produire une nouvelle exception en levant une exception (il vaut mieux quand même éviter de gratter les plaie au couteaux ).