Quelqu'un pourrait me dire pourquoi la classe Exception implèmente
l'interface ISerializable, alors qu'elle est déjà marquée avec l'attribut
[Serializable] ?
En d'autres termes, pourquoi Microsoft impose à toutes les exceptions qui
dériveront de la classe Exception (directement ou non) de contrôler leur
processus de sérialisation ?
La classe Exception aurait pu utiliser tout simplement la sérialisation par
défaut que propose l'attribut [Serializable] et laisser les autres exceptions
décider s'il est nécessaire qu'elles contrôlent ou non leur processus de
sérialisation.
Quelque chose m'échappe ...
Merci pour votre aide.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Sylvain Lafontaine
Plusieurs erreurs/exceptions peuvent survenir en même temps et ces exceptions peuvent être enchaînées l'une à la suite de l'autre. Il est donc nécessaire qu'elles partagent toutes une interface commune, sinon un programmeur cherchant à codifier la sérialisation d'une liste d'exceptions survenues serait bloqué par la présence d'une exception non connue ne supportant pas l'interface commune.
S. L.
"ShadowFil" wrote in message news:
Bonjour,
Quelqu'un pourrait me dire pourquoi la classe Exception implèmente l'interface ISerializable, alors qu'elle est déjà marquée avec l'attribut [Serializable] ?
En d'autres termes, pourquoi Microsoft impose à toutes les exceptions qui dériveront de la classe Exception (directement ou non) de contrôler leur processus de sérialisation ? La classe Exception aurait pu utiliser tout simplement la sérialisation par défaut que propose l'attribut [Serializable] et laisser les autres exceptions décider s'il est nécessaire qu'elles contrôlent ou non leur processus de sérialisation.
Quelque chose m'échappe ... Merci pour votre aide.
Plusieurs erreurs/exceptions peuvent survenir en même temps et ces
exceptions peuvent être enchaînées l'une à la suite de l'autre. Il est donc
nécessaire qu'elles partagent toutes une interface commune, sinon un
programmeur cherchant à codifier la sérialisation d'une liste d'exceptions
survenues serait bloqué par la présence d'une exception non connue ne
supportant pas l'interface commune.
S. L.
"ShadowFil" <ShadowFil@discussions.microsoft.com> wrote in message
news:180D1A5F-013F-45D4-BAA9-CBFFBC4B2FE8@microsoft.com...
Bonjour,
Quelqu'un pourrait me dire pourquoi la classe Exception implèmente
l'interface ISerializable, alors qu'elle est déjà marquée avec l'attribut
[Serializable] ?
En d'autres termes, pourquoi Microsoft impose à toutes les exceptions qui
dériveront de la classe Exception (directement ou non) de contrôler leur
processus de sérialisation ?
La classe Exception aurait pu utiliser tout simplement la sérialisation
par
défaut que propose l'attribut [Serializable] et laisser les autres
exceptions
décider s'il est nécessaire qu'elles contrôlent ou non leur processus de
sérialisation.
Quelque chose m'échappe ...
Merci pour votre aide.
Plusieurs erreurs/exceptions peuvent survenir en même temps et ces exceptions peuvent être enchaînées l'une à la suite de l'autre. Il est donc nécessaire qu'elles partagent toutes une interface commune, sinon un programmeur cherchant à codifier la sérialisation d'une liste d'exceptions survenues serait bloqué par la présence d'une exception non connue ne supportant pas l'interface commune.
S. L.
"ShadowFil" wrote in message news:
Bonjour,
Quelqu'un pourrait me dire pourquoi la classe Exception implèmente l'interface ISerializable, alors qu'elle est déjà marquée avec l'attribut [Serializable] ?
En d'autres termes, pourquoi Microsoft impose à toutes les exceptions qui dériveront de la classe Exception (directement ou non) de contrôler leur processus de sérialisation ? La classe Exception aurait pu utiliser tout simplement la sérialisation par défaut que propose l'attribut [Serializable] et laisser les autres exceptions décider s'il est nécessaire qu'elles contrôlent ou non leur processus de sérialisation.
Quelque chose m'échappe ... Merci pour votre aide.
Sylvain Lafontaine
De plus, la gestion des erreurs est déjà assez compliquée comme cela sans que les programmeurs ne doivent en plus commencer à se farcir toutes une série de protocols différents pour chacune des exceptions possibles.
Les exceptions sont là pour indiquer une erreur, alors ce n'est pas vraiment le temps de commencer à fouiller dans la définition de classe de chacune pour savoir comment on doit programmer avec.
S. L.
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> wrote in message news:
Plusieurs erreurs/exceptions peuvent survenir en même temps et ces exceptions peuvent être enchaînées l'une à la suite de l'autre. Il est donc nécessaire qu'elles partagent toutes une interface commune, sinon un programmeur cherchant à codifier la sérialisation d'une liste d'exceptions survenues serait bloqué par la présence d'une exception non connue ne supportant pas l'interface commune.
S. L.
"ShadowFil" wrote in message news:
Bonjour,
Quelqu'un pourrait me dire pourquoi la classe Exception implèmente l'interface ISerializable, alors qu'elle est déjà marquée avec l'attribut [Serializable] ?
En d'autres termes, pourquoi Microsoft impose à toutes les exceptions qui dériveront de la classe Exception (directement ou non) de contrôler leur processus de sérialisation ? La classe Exception aurait pu utiliser tout simplement la sérialisation par défaut que propose l'attribut [Serializable] et laisser les autres exceptions décider s'il est nécessaire qu'elles contrôlent ou non leur processus de sérialisation.
Quelque chose m'échappe ... Merci pour votre aide.
De plus, la gestion des erreurs est déjà assez compliquée comme cela sans
que les programmeurs ne doivent en plus commencer à se farcir toutes une
série de protocols différents pour chacune des exceptions possibles.
Les exceptions sont là pour indiquer une erreur, alors ce n'est pas vraiment
le temps de commencer à fouiller dans la définition de classe de chacune
pour savoir comment on doit programmer avec.
S. L.
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message news:u13IOp5EFHA.3536@TK2MSFTNGP15.phx.gbl...
Plusieurs erreurs/exceptions peuvent survenir en même temps et ces
exceptions peuvent être enchaînées l'une à la suite de l'autre. Il est
donc nécessaire qu'elles partagent toutes une interface commune, sinon un
programmeur cherchant à codifier la sérialisation d'une liste d'exceptions
survenues serait bloqué par la présence d'une exception non connue ne
supportant pas l'interface commune.
S. L.
"ShadowFil" <ShadowFil@discussions.microsoft.com> wrote in message
news:180D1A5F-013F-45D4-BAA9-CBFFBC4B2FE8@microsoft.com...
Bonjour,
Quelqu'un pourrait me dire pourquoi la classe Exception implèmente
l'interface ISerializable, alors qu'elle est déjà marquée avec l'attribut
[Serializable] ?
En d'autres termes, pourquoi Microsoft impose à toutes les exceptions qui
dériveront de la classe Exception (directement ou non) de contrôler leur
processus de sérialisation ?
La classe Exception aurait pu utiliser tout simplement la sérialisation
par
défaut que propose l'attribut [Serializable] et laisser les autres
exceptions
décider s'il est nécessaire qu'elles contrôlent ou non leur processus de
sérialisation.
Quelque chose m'échappe ...
Merci pour votre aide.
De plus, la gestion des erreurs est déjà assez compliquée comme cela sans que les programmeurs ne doivent en plus commencer à se farcir toutes une série de protocols différents pour chacune des exceptions possibles.
Les exceptions sont là pour indiquer une erreur, alors ce n'est pas vraiment le temps de commencer à fouiller dans la définition de classe de chacune pour savoir comment on doit programmer avec.
S. L.
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> wrote in message news:
Plusieurs erreurs/exceptions peuvent survenir en même temps et ces exceptions peuvent être enchaînées l'une à la suite de l'autre. Il est donc nécessaire qu'elles partagent toutes une interface commune, sinon un programmeur cherchant à codifier la sérialisation d'une liste d'exceptions survenues serait bloqué par la présence d'une exception non connue ne supportant pas l'interface commune.
S. L.
"ShadowFil" wrote in message news:
Bonjour,
Quelqu'un pourrait me dire pourquoi la classe Exception implèmente l'interface ISerializable, alors qu'elle est déjà marquée avec l'attribut [Serializable] ?
En d'autres termes, pourquoi Microsoft impose à toutes les exceptions qui dériveront de la classe Exception (directement ou non) de contrôler leur processus de sérialisation ? La classe Exception aurait pu utiliser tout simplement la sérialisation par défaut que propose l'attribut [Serializable] et laisser les autres exceptions décider s'il est nécessaire qu'elles contrôlent ou non leur processus de sérialisation.
Quelque chose m'échappe ... Merci pour votre aide.
Arnaud Debaene
ShadowFil wrote:
Bonjour,
Quelqu'un pourrait me dire pourquoi la classe Exception implèmente l'interface ISerializable, alors qu'elle est déjà marquée avec l'attribut [Serializable] ?
En d'autres termes, pourquoi Microsoft impose à toutes les exceptions qui dériveront de la classe Exception (directement ou non) de contrôler leur processus de sérialisation ? La classe Exception aurait pu utiliser tout simplement la sérialisation par défaut que propose l'attribut [Serializable] et laisser les autres exceptions décider s'il est nécessaire qu'elles contrôlent ou non leur processus de sérialisation.
Une exception peut "remonter" à travers du .NET remoting. Hors, pour pouvoir transmettre correctement une exception sur le réseau, le système de remoting a besoin d'avoir une version sérialisée complète de l'exception, de anière à ce que toutes les informations intéressantes de l'exception soient transmises. Autrement dit, les exceptions doivent implémenter ISerializable de manière à pouvoir être transmises entièrement et correctement quand une exception est lancée sur un objet distant.
Arnaud MVP - VC
ShadowFil wrote:
Bonjour,
Quelqu'un pourrait me dire pourquoi la classe Exception implèmente
l'interface ISerializable, alors qu'elle est déjà marquée avec
l'attribut [Serializable] ?
En d'autres termes, pourquoi Microsoft impose à toutes les exceptions
qui dériveront de la classe Exception (directement ou non) de
contrôler leur processus de sérialisation ?
La classe Exception aurait pu utiliser tout simplement la
sérialisation par défaut que propose l'attribut [Serializable] et
laisser les autres exceptions décider s'il est nécessaire qu'elles
contrôlent ou non leur processus de sérialisation.
Une exception peut "remonter" à travers du .NET remoting. Hors, pour pouvoir
transmettre correctement une exception sur le réseau, le système de remoting
a besoin d'avoir une version sérialisée complète de l'exception, de anière à
ce que toutes les informations intéressantes de l'exception soient
transmises. Autrement dit, les exceptions doivent implémenter ISerializable
de manière à pouvoir être transmises entièrement et correctement quand une
exception est lancée sur un objet distant.
Quelqu'un pourrait me dire pourquoi la classe Exception implèmente l'interface ISerializable, alors qu'elle est déjà marquée avec l'attribut [Serializable] ?
En d'autres termes, pourquoi Microsoft impose à toutes les exceptions qui dériveront de la classe Exception (directement ou non) de contrôler leur processus de sérialisation ? La classe Exception aurait pu utiliser tout simplement la sérialisation par défaut que propose l'attribut [Serializable] et laisser les autres exceptions décider s'il est nécessaire qu'elles contrôlent ou non leur processus de sérialisation.
Une exception peut "remonter" à travers du .NET remoting. Hors, pour pouvoir transmettre correctement une exception sur le réseau, le système de remoting a besoin d'avoir une version sérialisée complète de l'exception, de anière à ce que toutes les informations intéressantes de l'exception soient transmises. Autrement dit, les exceptions doivent implémenter ISerializable de manière à pouvoir être transmises entièrement et correctement quand une exception est lancée sur un objet distant.
