"Arnaud Lhopiteau" a écrit dans le message de groupe de discussion :
Dans le cas d'un nombre illimité de types, la solution qui me vient à l'esprit, c'est de déclarer au conteneur (le cache) que l'on utilise l'objet puis qu'on le libère.
Un problème qui se pose est que rien ne peut empêcher le contournement de ces méthodes.
"Arnaud Lhopiteau" <alhopiteau@gmail.com> a écrit dans le message de groupe
de discussion :
22e7ee34-c87e-4636-83bc-a956276b3959@u18g2000pro.googlegroups.com...
Dans le cas d'un nombre illimité de types, la solution qui me vient à
l'esprit, c'est de déclarer au conteneur (le cache) que l'on utilise
l'objet puis qu'on le libère.
Un problème qui se pose est que rien ne peut empêcher le contournement de
ces méthodes.
"Arnaud Lhopiteau" a écrit dans le message de groupe de discussion :
Dans le cas d'un nombre illimité de types, la solution qui me vient à l'esprit, c'est de déclarer au conteneur (le cache) que l'on utilise l'objet puis qu'on le libère.
Un problème qui se pose est que rien ne peut empêcher le contournement de ces méthodes.
Jérémy Jeanson
Bonjour tout le monde,
Si j'ai bien suivi les propos de Arnaud on pourrait éviter le contournement des méthodes dont parle Christophe en utilisant (attention: le mot n'est pas juste, mais l'idée y est) une classe qui fonctionnerait comme une fabrique du fameux pattern du même non.
Cette classe réaliserait l'ensemble des tâches énumérées par Arnaud et garderait à disposition ces objets en les protégeant d'éventuelles actions mal venues (libération imprévue de ressources et autre joyeusetés) en utilisant proprement les références faibles ou fortes.
Ah ce sujet j'avais un vieux lien de côté : http://weblogs.asp.net/craigg/archive/2004/02/26/Weak-References_2C00_-when-to-use_3F00_.aspx il contient un résumé plutôt simple sur les weakreference mais surtout les liens de la MSDN, toujours sympa à avoir sous la main, même si maintenant je pense qu'on doit avoir la même chose sur la MSDN en français. -- Jérémy JEANSON MCP http://www.jjeanson.fr
Bonjour tout le monde,
Si j'ai bien suivi les propos de Arnaud on pourrait éviter le
contournement des méthodes dont parle Christophe en utilisant
(attention: le mot n'est pas juste, mais l'idée y est) une classe qui
fonctionnerait comme une fabrique du fameux pattern du même non.
Cette classe réaliserait l'ensemble des tâches énumérées par Arnaud et
garderait à disposition ces objets en les protégeant d'éventuelles
actions mal venues (libération imprévue de ressources et autre
joyeusetés) en utilisant proprement les références faibles ou fortes.
Ah ce sujet j'avais un vieux lien de côté :
http://weblogs.asp.net/craigg/archive/2004/02/26/Weak-References_2C00_-when-to-use_3F00_.aspx
il contient un résumé plutôt simple sur les weakreference mais surtout
les liens de la MSDN, toujours sympa à avoir sous la main, même si
maintenant je pense qu'on doit avoir la même chose sur la MSDN en français.
--
Jérémy JEANSON
MCP
http://www.jjeanson.fr
Si j'ai bien suivi les propos de Arnaud on pourrait éviter le contournement des méthodes dont parle Christophe en utilisant (attention: le mot n'est pas juste, mais l'idée y est) une classe qui fonctionnerait comme une fabrique du fameux pattern du même non.
Cette classe réaliserait l'ensemble des tâches énumérées par Arnaud et garderait à disposition ces objets en les protégeant d'éventuelles actions mal venues (libération imprévue de ressources et autre joyeusetés) en utilisant proprement les références faibles ou fortes.
Ah ce sujet j'avais un vieux lien de côté : http://weblogs.asp.net/craigg/archive/2004/02/26/Weak-References_2C00_-when-to-use_3F00_.aspx il contient un résumé plutôt simple sur les weakreference mais surtout les liens de la MSDN, toujours sympa à avoir sous la main, même si maintenant je pense qu'on doit avoir la même chose sur la MSDN en français. -- Jérémy JEANSON MCP http://www.jjeanson.fr
Arnaud Lhopiteau
> Un problème qui se pose est que rien ne peut empêcher le contournemen t de ces méthodes.
Tout ceci nous ramène aux mêmes problêmes d'utilisation que connait la technologie COM/COM+/DCOM qui utilise des compteurs de référence pas toujours mis à jour...
> Un problème qui se pose est que rien ne peut empêcher le contournemen t de
ces méthodes.
Tout ceci nous ramène aux mêmes problêmes d'utilisation que connait
la
technologie COM/COM+/DCOM qui utilise des compteurs de référence pas
toujours mis à jour...
> Un problème qui se pose est que rien ne peut empêcher le contournemen t de ces méthodes.
Tout ceci nous ramène aux mêmes problêmes d'utilisation que connait la technologie COM/COM+/DCOM qui utilise des compteurs de référence pas toujours mis à jour...
Arnaud Lhopiteau
On 11 déc, 09:02, Jérémy Jeanson wrote:
Bonjour tout le monde,
Si j'ai bien suivi les propos de Arnaud on pourrait éviter le contournement des méthodes dont parle Christophe en utilisant (attention: le mot n'est pas juste, mais l'idée y est) une classe qui fonctionnerait comme une fabrique du fameux pattern du même non.
Cette classe réaliserait l'ensemble des tâches énumérées par Ar naud et garderait à disposition ces objets en les protégeant d'éventuelles actions mal venues (libération imprévue de ressources et autre joyeusetés) en utilisant proprement les références faibles ou forte s.
Ah ce sujet j'avais un vieux lien de côté :http://weblogs.asp.net/cra igg/archive/2004/02/26/Weak-References_2C00... il contient un résumé plutôt simple sur les weakreference mais surt out les liens de la MSDN, toujours sympa à avoir sous la main, même si maintenant je pense qu'on doit avoir la même chose sur la MSDN en fran çais. -- Jérémy JEANSON MCPhttp://www.jjeanson.fr
En fait, l 'objet cache a ce rôle de Factory, car il met à dispositions ces objets. Si on ne peut "wrapper" les références pour que les compteurs d'utilisation soient décrémentés lorsque ces "wrappers" sont recycl és, je ne vois que la solution "façon COM".
On 11 déc, 09:02, Jérémy Jeanson <jeremy.jean...@free.fr> wrote:
Bonjour tout le monde,
Si j'ai bien suivi les propos de Arnaud on pourrait éviter le
contournement des méthodes dont parle Christophe en utilisant
(attention: le mot n'est pas juste, mais l'idée y est) une classe qui
fonctionnerait comme une fabrique du fameux pattern du même non.
Cette classe réaliserait l'ensemble des tâches énumérées par Ar naud et
garderait à disposition ces objets en les protégeant d'éventuelles
actions mal venues (libération imprévue de ressources et autre
joyeusetés) en utilisant proprement les références faibles ou forte s.
Ah ce sujet j'avais un vieux lien de côté :http://weblogs.asp.net/cra igg/archive/2004/02/26/Weak-References_2C00...
il contient un résumé plutôt simple sur les weakreference mais surt out
les liens de la MSDN, toujours sympa à avoir sous la main, même si
maintenant je pense qu'on doit avoir la même chose sur la MSDN en fran çais.
--
Jérémy JEANSON
MCPhttp://www.jjeanson.fr
En fait, l 'objet cache a ce rôle de Factory, car il met à
dispositions ces objets.
Si on ne peut "wrapper" les références pour que les compteurs
d'utilisation soient décrémentés lorsque ces "wrappers" sont recycl és,
je ne vois que la solution "façon COM".
Si j'ai bien suivi les propos de Arnaud on pourrait éviter le contournement des méthodes dont parle Christophe en utilisant (attention: le mot n'est pas juste, mais l'idée y est) une classe qui fonctionnerait comme une fabrique du fameux pattern du même non.
Cette classe réaliserait l'ensemble des tâches énumérées par Ar naud et garderait à disposition ces objets en les protégeant d'éventuelles actions mal venues (libération imprévue de ressources et autre joyeusetés) en utilisant proprement les références faibles ou forte s.
Ah ce sujet j'avais un vieux lien de côté :http://weblogs.asp.net/cra igg/archive/2004/02/26/Weak-References_2C00... il contient un résumé plutôt simple sur les weakreference mais surt out les liens de la MSDN, toujours sympa à avoir sous la main, même si maintenant je pense qu'on doit avoir la même chose sur la MSDN en fran çais. -- Jérémy JEANSON MCPhttp://www.jjeanson.fr
En fait, l 'objet cache a ce rôle de Factory, car il met à dispositions ces objets. Si on ne peut "wrapper" les références pour que les compteurs d'utilisation soient décrémentés lorsque ces "wrappers" sont recycl és, je ne vois que la solution "façon COM".
Christophe Lephay
"Arnaud Lhopiteau" a écrit dans le message de groupe de discussion :
Un problème qui se pose est que rien ne peut empêcher le contournement de ces méthodes.
Tout ceci nous ramène aux mêmes problêmes d'utilisation que connait la technologie COM/COM+/DCOM qui utilise des compteurs de référence pas toujours mis à jour...
Tout à fait.
Sans surcharge possible de l'opérateur d'affectation, il est impossible de garantir une incrémentation correcte des références.
Sans appel garanti des destructeurs, il en est de même de leur décrémentation.
Il est impossible d'imaginer une solution satisfaisante sans avoir une définition plus précise du problème que doit permettre de résoudre le cache.
"Arnaud Lhopiteau" <alhopiteau@gmail.com> a écrit dans le message de groupe
de discussion :
86bbd1f2-1e38-4ba8-a85c-a2d962dad7aa@y1g2000pra.googlegroups.com...
Un problème qui se pose est que rien ne peut empêcher le contournement de
ces méthodes.
Tout ceci nous ramène aux mêmes problêmes d'utilisation que connait
la
technologie COM/COM+/DCOM qui utilise des compteurs de référence pas
toujours mis à jour...
Tout à fait.
Sans surcharge possible de l'opérateur d'affectation, il est impossible de
garantir une incrémentation correcte des références.
Sans appel garanti des destructeurs, il en est de même de leur
décrémentation.
Il est impossible d'imaginer une solution satisfaisante sans avoir une
définition plus précise du problème que doit permettre de résoudre le cache.
"Arnaud Lhopiteau" a écrit dans le message de groupe de discussion :
Un problème qui se pose est que rien ne peut empêcher le contournement de ces méthodes.
Tout ceci nous ramène aux mêmes problêmes d'utilisation que connait la technologie COM/COM+/DCOM qui utilise des compteurs de référence pas toujours mis à jour...
Tout à fait.
Sans surcharge possible de l'opérateur d'affectation, il est impossible de garantir une incrémentation correcte des références.
Sans appel garanti des destructeurs, il en est de même de leur décrémentation.
Il est impossible d'imaginer une solution satisfaisante sans avoir une définition plus précise du problème que doit permettre de résoudre le cache.
Jérémy Jeanson
A quand un event sur nos objets pour indiquer leur destruction? qui sait! -- Jérémy JEANSON MCP http://www.jjeanson.fr
A quand un event sur nos objets pour indiquer leur destruction? qui sait!
--
Jérémy JEANSON
MCP
http://www.jjeanson.fr
A quand un event sur nos objets pour indiquer leur destruction? qui sait! -- Jérémy JEANSON MCP http://www.jjeanson.fr
Christophe Lephay
"Jérémy Jeanson" a écrit dans le message de groupe de discussion :
A quand un event sur nos objets pour indiquer leur destruction? qui sait!
Le destructeur en est déjà un. Le problème est surtout qu'il est appelé lors du garbage collection et non lorsque l'objet n'est plus pointé par aucune référence.
Wrapper les objets dans des struct seraient une solution si seulement on pouvait définir y des destructeurs :/
"Jérémy Jeanson" <jeremy.jeanson@free.fr> a écrit dans le message de groupe
de discussion : enfFr43WJHA.5052@TK2MSFTNGP04.phx.gbl...
A quand un event sur nos objets pour indiquer leur destruction? qui sait!
Le destructeur en est déjà un. Le problème est surtout qu'il est appelé lors
du garbage collection et non lorsque l'objet n'est plus pointé par aucune
référence.
Wrapper les objets dans des struct seraient une solution si seulement on
pouvait définir y des destructeurs :/
"Jérémy Jeanson" a écrit dans le message de groupe de discussion :
A quand un event sur nos objets pour indiquer leur destruction? qui sait!
Le destructeur en est déjà un. Le problème est surtout qu'il est appelé lors du garbage collection et non lorsque l'objet n'est plus pointé par aucune référence.
Wrapper les objets dans des struct seraient une solution si seulement on pouvait définir y des destructeurs :/
Arnaud Lhopiteau
On 11 déc, 14:34, "Christophe Lephay" wrote:
"Jérémy Jeanson" a écrit dans le message d e groupe de discussion :
> A quand un event sur nos objets pour indiquer leur destruction? qui sai t!
Le destructeur en est déjà un. Le problème est surtout qu'il est ap pelé lors du garbage collection et non lorsque l'objet n'est plus pointé par aucu ne référence.
Wrapper les objets dans des struct seraient une solution si seulement on pouvait définir y des destructeurs :/
Ce qui n'est pas le cas, disons plutôt dans des objets normaux implémentant l'interface IDisposable, idéalement utilisé dans un bloc k "using".
On 11 déc, 14:34, "Christophe Lephay" <christophe-lep...@wanadoo.fr>
wrote:
"Jérémy Jeanson" <jeremy.jean...@free.fr> a écrit dans le message d e groupe
de discussion : enfFr43WJHA.5...@TK2MSFTNGP04.phx.gbl...
> A quand un event sur nos objets pour indiquer leur destruction? qui sai t!
Le destructeur en est déjà un. Le problème est surtout qu'il est ap pelé lors
du garbage collection et non lorsque l'objet n'est plus pointé par aucu ne
référence.
Wrapper les objets dans des struct seraient une solution si seulement on
pouvait définir y des destructeurs :/
Ce qui n'est pas le cas, disons plutôt dans des objets normaux
implémentant l'interface IDisposable, idéalement utilisé dans un bloc k
"using".
"Jérémy Jeanson" a écrit dans le message d e groupe de discussion :
> A quand un event sur nos objets pour indiquer leur destruction? qui sai t!
Le destructeur en est déjà un. Le problème est surtout qu'il est ap pelé lors du garbage collection et non lorsque l'objet n'est plus pointé par aucu ne référence.
Wrapper les objets dans des struct seraient une solution si seulement on pouvait définir y des destructeurs :/
Ce qui n'est pas le cas, disons plutôt dans des objets normaux implémentant l'interface IDisposable, idéalement utilisé dans un bloc k "using".
Jérémy Jeanson
Using :) oui, mais je ne suis pas un grand fan de son ecriture, je prefère largement le try, catch, finally car il est trsè rare que je n'ai qu'un objet IDisposable à manipuler à la foi.
Quelqun a t il dailler vu une reelle utilité de faire un code de ce genre dans le finally d'un méthode quand l'objet est déclaré en début de méthode?
Par exemple:
void Job() { ObjectDisposable obj = null;
try { // Le job à faire plus l'instanciation des objets obj = new ObjectDisposable (); // etc ... } catch(Exception ex) { // Gestion des erreurs } finally { // Libération des ressources // c'est cette partie qui m'interrese if(obj != null) obj.Dispose(); obj = null; } } -- Jérémy JEANSON MCP http://www.jjeanson.fr
Using :) oui, mais je ne suis pas un grand fan de son ecriture, je
prefère largement le try, catch, finally car il est trsè rare que je
n'ai qu'un objet IDisposable à manipuler à la foi.
Quelqun a t il dailler vu une reelle utilité de faire un code de ce
genre dans le finally d'un méthode quand l'objet est déclaré en début de
méthode?
Par exemple:
void Job()
{
ObjectDisposable obj = null;
try
{
// Le job à faire plus l'instanciation des objets
obj = new ObjectDisposable ();
// etc ...
}
catch(Exception ex)
{
// Gestion des erreurs
}
finally
{
// Libération des ressources
// c'est cette partie qui m'interrese
if(obj != null) obj.Dispose();
obj = null;
}
}
--
Jérémy JEANSON
MCP
http://www.jjeanson.fr
Using :) oui, mais je ne suis pas un grand fan de son ecriture, je prefère largement le try, catch, finally car il est trsè rare que je n'ai qu'un objet IDisposable à manipuler à la foi.
Quelqun a t il dailler vu une reelle utilité de faire un code de ce genre dans le finally d'un méthode quand l'objet est déclaré en début de méthode?
Par exemple:
void Job() { ObjectDisposable obj = null;
try { // Le job à faire plus l'instanciation des objets obj = new ObjectDisposable (); // etc ... } catch(Exception ex) { // Gestion des erreurs } finally { // Libération des ressources // c'est cette partie qui m'interrese if(obj != null) obj.Dispose(); obj = null; } } -- Jérémy JEANSON MCP http://www.jjeanson.fr
Christophe Lephay
"Jérémy Jeanson" a écrit dans le message de groupe de discussion :
Using :) oui, mais je ne suis pas un grand fan de son ecriture, je prefère largement le try, catch, finally car il est trsè rare que je n'ai qu'un objet IDisposable à manipuler à la foi.
using( DisposableTypeA DisposableObject1 = new DisposableTypeA(), DisposableObject2 = new DisposableTypeA(), DisposableObject3 = new DisposableTypeA()) using( DisposableTypeB DisposableObject4) { }
tous les objets créés dans les clauses using seront "Disposés" à la fin du bloc.
Quelqun a t il dailler vu une reelle utilité de faire un code de ce genre dans le finally d'un méthode quand l'objet est déclaré en début de méthode?
Par exemple:
void Job() { ObjectDisposable obj = null;
try { // Le job à faire plus l'instanciation des objets obj = new ObjectDisposable (); // etc ... } catch(Exception ex) { // Gestion des erreurs } finally { // Libération des ressources // c'est cette partie qui m'interrese if(obj != null) obj.Dispose(); obj = null; } }
Ben l'utilité consiste à appeler le Dispose de manière déterministe, ce qui est judicieux si l'objet consomme beaucoup de ressources.
Note que la version avec using serait quand même vachement plus simple (encore un sucre syntaxique bienvenu ;)).
Finally, ou using quand l'objet est disposable, permettent d'écrire du code qui soit "exception safe", c'est à dire du code qui garantisse d'avoir le programme ou les données dans un état connu en présence d'exception.
La particularité de ton code, et c'est peut-être ça qui y était important, c'est que tu as un catch qui intercepte tous les types d'exception. Dans ce cas précis, le finally n'apporte pas grand chose, à part éviter de dupliquer le code de nettoyage à la fin du try et dans le catch.
Un point essentiel est qu'en interceptant toutes les exceptions, tu ne peux pas garantir que ton programme ou tes données ne se trouve pas dans un état indéfini, ce qui peut avoir des conséquences potentiellement dramatiques.
C'est pour cette raison que la règle consiste à n'intercepter que les exceptions pour lesquelles on sait pertinemment quoi faire. C'est aussi pour cette raison qu'une exception non gérée interrompt l'application aussi vite que possible, parce que c'est généralement moins grave qu'un programme qui continue à s'exécuter dans un état indéterminé.
Si on n'intercepte pas tous les types d'exception, il n'y a pas d'alternative à using ou finally pour garantir la remise en ordre des données, si possible en l'état valide antérieur à la levée d'exception.
A noter que les exceptions sont un moyen privilégié pour une classe de maintenir ses invariants. Lorsqu'un invariant n'est plus maintenu, c'est qu'il y a un bug quelque part, et intercepter l'exception ne permet pas de l'identifier.
"Jérémy Jeanson" <jeremy.jeanson@free.fr> a écrit dans le message de groupe
de discussion : O4p98u5WJHA.5764@TK2MSFTNGP04.phx.gbl...
Using :) oui, mais je ne suis pas un grand fan de son ecriture, je prefère
largement le try, catch, finally car il est trsè rare que je n'ai qu'un
objet IDisposable à manipuler à la foi.
using( DisposableTypeA DisposableObject1 = new DisposableTypeA(),
DisposableObject2 = new DisposableTypeA(), DisposableObject3 = new
DisposableTypeA())
using( DisposableTypeB DisposableObject4)
{
}
tous les objets créés dans les clauses using seront "Disposés" à la fin du
bloc.
Quelqun a t il dailler vu une reelle utilité de faire un code de ce genre
dans le finally d'un méthode quand l'objet est déclaré en début de
méthode?
Par exemple:
void Job()
{
ObjectDisposable obj = null;
try
{
// Le job à faire plus l'instanciation des objets
obj = new ObjectDisposable ();
// etc ...
}
catch(Exception ex)
{
// Gestion des erreurs
}
finally
{
// Libération des ressources
// c'est cette partie qui m'interrese
if(obj != null) obj.Dispose();
obj = null;
}
}
Ben l'utilité consiste à appeler le Dispose de manière déterministe, ce qui
est judicieux si l'objet consomme beaucoup de ressources.
Note que la version avec using serait quand même vachement plus simple
(encore un sucre syntaxique bienvenu ;)).
Finally, ou using quand l'objet est disposable, permettent d'écrire du code
qui soit "exception safe", c'est à dire du code qui garantisse d'avoir le
programme ou les données dans un état connu en présence d'exception.
La particularité de ton code, et c'est peut-être ça qui y était important,
c'est que tu as un catch qui intercepte tous les types d'exception. Dans ce
cas précis, le finally n'apporte pas grand chose, à part éviter de dupliquer
le code de nettoyage à la fin du try et dans le catch.
Un point essentiel est qu'en interceptant toutes les exceptions, tu ne peux
pas garantir que ton programme ou tes données ne se trouve pas dans un état
indéfini, ce qui peut avoir des conséquences potentiellement dramatiques.
C'est pour cette raison que la règle consiste à n'intercepter que les
exceptions pour lesquelles on sait pertinemment quoi faire. C'est aussi pour
cette raison qu'une exception non gérée interrompt l'application aussi vite
que possible, parce que c'est généralement moins grave qu'un programme qui
continue à s'exécuter dans un état indéterminé.
Si on n'intercepte pas tous les types d'exception, il n'y a pas
d'alternative à using ou finally pour garantir la remise en ordre des
données, si possible en l'état valide antérieur à la levée d'exception.
A noter que les exceptions sont un moyen privilégié pour une classe de
maintenir ses invariants. Lorsqu'un invariant n'est plus maintenu, c'est
qu'il y a un bug quelque part, et intercepter l'exception ne permet pas de
l'identifier.
"Jérémy Jeanson" a écrit dans le message de groupe de discussion :
Using :) oui, mais je ne suis pas un grand fan de son ecriture, je prefère largement le try, catch, finally car il est trsè rare que je n'ai qu'un objet IDisposable à manipuler à la foi.
using( DisposableTypeA DisposableObject1 = new DisposableTypeA(), DisposableObject2 = new DisposableTypeA(), DisposableObject3 = new DisposableTypeA()) using( DisposableTypeB DisposableObject4) { }
tous les objets créés dans les clauses using seront "Disposés" à la fin du bloc.
Quelqun a t il dailler vu une reelle utilité de faire un code de ce genre dans le finally d'un méthode quand l'objet est déclaré en début de méthode?
Par exemple:
void Job() { ObjectDisposable obj = null;
try { // Le job à faire plus l'instanciation des objets obj = new ObjectDisposable (); // etc ... } catch(Exception ex) { // Gestion des erreurs } finally { // Libération des ressources // c'est cette partie qui m'interrese if(obj != null) obj.Dispose(); obj = null; } }
Ben l'utilité consiste à appeler le Dispose de manière déterministe, ce qui est judicieux si l'objet consomme beaucoup de ressources.
Note que la version avec using serait quand même vachement plus simple (encore un sucre syntaxique bienvenu ;)).
Finally, ou using quand l'objet est disposable, permettent d'écrire du code qui soit "exception safe", c'est à dire du code qui garantisse d'avoir le programme ou les données dans un état connu en présence d'exception.
La particularité de ton code, et c'est peut-être ça qui y était important, c'est que tu as un catch qui intercepte tous les types d'exception. Dans ce cas précis, le finally n'apporte pas grand chose, à part éviter de dupliquer le code de nettoyage à la fin du try et dans le catch.
Un point essentiel est qu'en interceptant toutes les exceptions, tu ne peux pas garantir que ton programme ou tes données ne se trouve pas dans un état indéfini, ce qui peut avoir des conséquences potentiellement dramatiques.
C'est pour cette raison que la règle consiste à n'intercepter que les exceptions pour lesquelles on sait pertinemment quoi faire. C'est aussi pour cette raison qu'une exception non gérée interrompt l'application aussi vite que possible, parce que c'est généralement moins grave qu'un programme qui continue à s'exécuter dans un état indéterminé.
Si on n'intercepte pas tous les types d'exception, il n'y a pas d'alternative à using ou finally pour garantir la remise en ordre des données, si possible en l'état valide antérieur à la levée d'exception.
A noter que les exceptions sont un moyen privilégié pour une classe de maintenir ses invariants. Lorsqu'un invariant n'est plus maintenu, c'est qu'il y a un bug quelque part, et intercepter l'exception ne permet pas de l'identifier.
