Discussion :

[Chekov]

Bonjour,

je ne crois pas que ce soit possible : j'ai un objet (je n'ai pas accès à son code source) qui génère une exception lors de sa destruction, dans certaines situations. Comme cette exception n'est pas gérée par cet objet, ça fait crasher mon programme...

Existe-t-il une astuce pour rattraper celle-ci ?

[Greybird]

Quant tu parles de destruction, parles-tu de l'appel à Dispose ? de l'appel au finaliseur ?
Quel est le type d'exception ? As-tu analysé le code avec Reflector pour déterminer ce qui pose réellement le problème ?

Un premier moyen de gérer cette exception serait de brancher l'event handler appelé pour toutes les exceptions non gérées de l'application (la façon de faire ça dépend du type de ton application, console ou WinForms) et de disposer d'une façon d'identifier cette exception problématique pour ensuite l'ignorer.

Un meilleur moyen, mais pas forcément possible, est de dériver le composant et de corriger le comportement fautif. Ce n'est pas toujours possible, et ça nécessite d'avoir un certain nombre d'informations telles que celles que je te cite en début de post.

Le tout combiné à un signalement de bug au fournisseur de ces composants :p

[Chekov]

Ok... je ne connais pas Reflector, je vais regarder ça.

je rencontre le problème avec la classe SerialPort dans ce cas:

j'utilise un cable USB/RS-232. J'ouvre le port COM correspondant au câble lorsqu'il est branché, je débranche sauvagement le câble (le périphérique disparait du Gestionnaire de Périphériques), je ferme le programme qui avait le port COM ouvert et là.... exception. Je pense que ça se produit lorsque SerialPort se détruit et tente de fermer le flux du port.

[NiamorH]

Une des règles de base en programmation (en C++ en tout cas) est de ne jamais lever d'exceptions dans les destructeurs. Est-ce courant en C# ?

[sisqo60]

c'est assez bizarre ce que tu dis, mais tu peux limiter la casse en entourant le destruction de l'object par un try/catch ou même overrider cette class d'objet(si elle n'est pas déclarée sealed)... juste pour éviter de bugger.
C'est une bidouille bien sur mais quand c'est pas du code que tu as fait, des fois tu n'as pas le choix...

[Guulh]

Une des règles de base en programmation (en C++ en tout cas) est de ne jamais lever d'exceptions dans les destructeurs. Est-ce courant en C# ?

Ca serait même encore plus critique en C# et plus généralement pour tout langage à GC, puisque le code de finalisation est exécuté par le GC quand ça lui chante, de façon non déterministe. On ne peut pas entourer un finaliseur par un try catch, puisque le finaliseur n'est pas appelé par notre code.

Un petit coup de google donne : http://support.microsoft.com/kb/952897
MS connait le problème, mais ne fournit pas de moyen de le résoudre

[Edit]Après encore un peu plus de google, la seule solution semble être ça :
http://connect.microsoft.com/VisualS...dbackID=140018

As well as enabling legacy exception handling, you need to subscribe to the Application.ThreadException and CurrentDomain.UnhandledException and then you can see whether the exception was caused by the serial port using something like:

if (!((Exception)e.ExceptionObject).StackTrace.Contains("System.IO.Ports.SerialStream.EventLoopRunner.WaitForCommEvent()"))

and do whatever you see fit. I also find that it helps if you get the SerialPort.BaseStream member as soon as you open the port, you can then close the stream within a try/catch and then close the port within a try/catch.

Donc en gros, tu peux pas empêcher l'exception d'arriver, tu peux pas la try-catcher directement, mais en s'abonnant à l'événement UnhandledException, tu peux la récupérer et arrêter sa propagation.

[Chekov]

Merci beaucoup pour toutes ces infos, ça devrait bien m'aider (quand j'aurai assimilé tout ça ).

J'ai lu par mal de forums, et j'ai cru comprendre que la classe SerialPort souffrait de quelques défauts dont celui-ci et un autre: la méthode .Close() ne rend parfois pas la main si une autre opération est en cours sur le port (genre ReadLine()) et peut faire un deadlock. C'est pas cool ...

Si quelqu'un sait comment contourner ce genre de problèmes, je suis preneur :-)