Discussion :

[nikoko34]

Bonjour à tous,

Je suis en train de tester dans une application les exceptions non managées (de type OutOfMemory par exemple), et, la précision sera peut être utile, sous #Develop V2.

J'ai donc d'abord attentivement lu les discussions existantes à ce sujet (en VB et C#) ce qui m'a (presque) permis de me débrouiller tout seul comme un grand
Voici le contenu du Program.VB

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
18
19
20
21
Partial Class MyApplication
Public Sub New()
	MyBase.New(AuthenticationMode.Windows)
	Me.IsSingleInstance = False
	Me.EnableVisualStyles = True
	Me.SaveMySettingsOnExit = False ' MySettings are not supported in SharpDevelop.
	Me.ShutDownStyle = ShutdownMode.AfterMainFormCloses
	'TODO: following line does not work!
	'application.SetUnhandledExceptionMode(UnhandledExceptionMode.Automatic)
 
	Dim currentDomain As AppDomain = AppDomain.CurrentDomain
	AddHandler CurrentDomain.UnhandledException, AddressOf ManageUnhandledException
End Sub
 
Protected Overrides Sub OnCreateMainForm()
	Me.MainForm = My.Forms.MainForm
End Sub
 
Sub ManageUnhandledException(sender As Object, e As system.UnhandledExceptionEventArgs)
	msgbox("J'ai trouvé une exception non gérée !")
End Sub

A partir de là, je rencontre les problèmes suivants quand une exception est levée et je précise que ces problèmes sont identiques que l'on soit en mode Debug ou Release :

1) Le msgbox ("J'ai trouvé une exception non gérée !") s'affiche quand le programme est executée depuis l'IDE de #Develop mais pas à partir de l'exe généré.

2) Dans les deux cas, le fenêtre d'exception (celle avec la croix rouge) s'affiche par la suite (exemple : System.IndexOutOfRangeException was thrown in debuggee:...) alors que je souhaiterais ne pas l'afficher justement puisque je gère moi même l'exception !

3) J'ai voulu définir la valeur du mode de gestion des exceptions (application.SetUnhandledExceptionMode) pour à priori résoudre le point précédent. La méthode (en commentaire dans le code ci-dessus) est bien proposée en Auto-Complétion mais la compilation ne la reconnait pas !

4) Mon code ne comporte pas de application.run ni de procédure Main, tout ceci a été généré avec le wizard de #Develop. Est ce que ceci explique celà ?

Merci par avance de vos réponses parce que là, ça coince !

[tomlev]

Le fait de gérer l'évènement UnhandledException n'intercepte pas l'exception, ça te permet seulement d'en être informé. Pour intercepter une exception quand elle se produit et l'empêcher de terminer le programme, utilise des blocs try/catch

[Pol63]

+1

et si tu mets des try catch un peu partout le risque d'unhandledexception arrive pas loin de 0

car meme certains outofmemory peuvent etre intercepté et ne pas arreter l'appli

[nikoko34]

Merci de votre réponse.

@Sperot : Je mets effectivement des Try/Catch un peu partout mais les exceptions que je catche sont spécifiques, comme celà est recommandé, afin de ne pas trop nuire aux performances (exemple IO si la méthode lit un fichier).

@Tomlev : Si je met un Try/Catch dans le code qui gère les unhandled, celà ne change rien. Peut-être un Try/Catch au niveau le plus haut de l'application (dans le OnCreateMainForm) ?

[karlus]

as tu essayé de t'abonner également à

Code :

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

1
2
 
Application.ThreadException

sinon un try catch autour du main devrait être possible

[tomlev]

@Tomlev : Si je met un Try/Catch dans le code qui gère les unhandled, celà ne change rien. Peut-être un Try/Catch au niveau le plus haut de l'application (dans le OnCreateMainForm) ?

Dans le handler de l'évènement UnhandledException, c'est déjà trop tard pour intercepter l'exception... il faut le faire dans la méthode qui provoque l'exception

[nikoko34]

@Karlus: Application.ThreadException n'est pas accepté en compilation, et ce pour la même raison que application.SetUnhandledExceptionMode, c'est à dire que c'est proposé par l'autocomplétion mais refusé sous le motif "ThreadException" is not an event of <appli>.My.MyApplication

On dirait en fait qu'il y a un cast (selon le type d'application ?) au démarrage depuis la classe Application vers le MyApplication et que certaines méthodes ou evènement sont désactivés suite à ce cast ! Pas glop, tout ça...

Merci Tomlev, pour cette info. Mais donc, si je te comprends bien, on en revient à mettre du try catch partout avec le type générique "Exception", ce que je voulais éviter.

Je cherchais justement à le mettre à un niveau plus élevé (style la mainform) pour gérer ce type d'exception imprévu en me disant qu'en cas d'exception, la pile des appels est "dépilée" jusqu'à trouver un bloc Try/Catch (si pas trouvé alors, on avait droit au message standard d'exception).

[karlus]

Ton appli est bien du type winform ? Pour une appli winform Application.ThreadException est tout à fait valide.
N'y a t-il pas un problème avec l'utilisation du wizard #develop ? ( pas de main, pas d'application.Run() pour une appli winform ce n'est pas normal )

[nikoko34]

Oui, Karlus, c'est bien du WinForm et oui, il est fort possible que le wizard soit partiellement fautif.

Je vérifierai sur un autre poste qui contient la version express de VB.

Je viens aussi de fouiner du coté du fichier Machine.config car il semble que le fait de mettre jitDebugging="true" puisse éviter l'affichage du message d'exception standard de DotNet.

Si quelqu'un a fouiné là dedans, je suis preneur !

[Pol63]

@Sperot : Je mets effectivement des Try/Catch un peu partout mais les exceptions que je catche sont spécifiques, comme celà est recommandé, afin de ne pas trop nuire aux performances (exemple IO si la méthode lit un fichier).

je suis pas sur que catcher de manière spécifique gagne du temps, je pense que dès l'instant qu'on est dans un try, l'exception est créée, et c'est ca qui prend du temps

de plus tu peux mettre des try catch partout, tu ne verras pas à l'oeil nu des diffrences de perfs !
y a eut des benchs de fait, c'est pas violent, et puis si on veut pas que l'appli s'arrete, y a pas 36 moyens

après ca dépend aussi de ce que tu en fais des exception ...

recommandé

recommandé par qui ?

[karlus]

Je viens aussi de fouiner du coté du fichier Machine.config car il semble que le fait de mettre jitDebugging="true" puisse éviter l'affichage du message d'exception standard de DotNet.

Tu peux modifier le debug JIT via une clé du registre, mais c'est vraiment une solution de contournement assez "osée" je trouve d'autant que cela à un effet sur l'ensemble des applications installées

[nikoko34]

recommandé par qui ?

Et bien notament par cet article
http://blog.developpez.com/adiguba?t...t_performances
(c'est du Java mais je me dis que ça ne change pas le raisonnement)

En fait, je me dis que si je ne met que des try/Catch là où une exception est susceptible de se produire (IO par exemple) et que j'arrive à mettre en place un Try/Catch global pour les exceptions non prévisibles, je peux m'y retrouver en terme de perf sachant que mes programmes sont essentiellement basés sur des calculs itératifs portant sur des grands volumes de données.
Quand une exception non prévisible survient, je veux pouvoir soit revenir à la fenêtre principale, soit pauser l'appli, soit la quitter.

Après vérification, le JIT sert à trancher entre l'affiche de l'exception façon DotNet (permettant donc de continuer ou d'arrêter l'appli) et le message de Windows quand une application plante.
Donc, ce n'était pas le bon raisonnement.

En tout cas, merci à vous trois de vous interesser à mon cas

[Pol63]

ca pourrait rejoindre ce que je dis, en cas de levée d'exception, ca instancie un objet complexe qui enregistre la pile des appels entre autre
donc normal que c'est long


mais tant qu'il n'y a pas d'erreur, les try catch sont insignifiant sur les pc de nos jours
et en théorie ton code ne doit pas être truffé d'erreur


unhandledexception existe à des fins de débug, pouvoir enregistrer des erreurs rares et non localisées, ca n'empeche pas l'appli de s'arreter

[nikoko34]

Merci Sperot, pour le compliment
Mince, y'avait écrit "en théorie", j'ai cru que ça m'était adressé...

Je viens de nettement décoincer la situation alors je vous fournis les éléments:

1) Dans le New de ma MainForm, je met ceci

Code :

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

1
2
3
AddHandler application.ThreadException, AddressOf ManageThreadException
Dim currentDomain As AppDomain = AppDomain.CurrentDomain
AddHandler CurrentDomain.UnhandledException, AddressOf ManageUnhandledException

2) Les deux méthodes ManageThreadException et ManageUnhandledException gèrent l'exception non prévue (par exemple, l'affichage d'une form générique indiquant les propriétés/types de l'exception, identique à celle que l'on afficherait dans les blocs de Catch)

3) Quand l'appli est lancée depuis l'IDE, c'est ManageUnhandledException qui se déclenche alors que si on la lance depuis l'EXE, la même erreur déclenche l'event ManageThreadException (ne me demandez pas pourquoi le comportement change !)

4) La commande Application.ThreadException est bien accepté dans le projet mais PAS dans le program.vb

Il semble qu'avec ce mécanisme, toute exception déclenchée sans try/catch est bien routée même dans d'autres fenêtres que la MainForm !

[Pol63]

j'ai retrouvé le lien grace un c#ien

http://www.codeproject.com/KB/except...rformance.aspx

on voit bien que tant qu'aucune exception n'est levée, c'est pouillièmes de perf en moins (entre 0 et 2% selon la taille de la sub)

[nikoko34]

j'ai retrouvé le lien grace un c#ien

http://www.codeproject.com/KB/except...rformance.aspx

on voit bien que tant qu'aucune exception n'est levée, c'est pouillièmes de perf en moins (entre 0 et 2% selon la taille de la sub)

Merci Sperot, je vais zieuter tout ça.

De toute façon, la solution que je compte implémenter est vraiment destinée aux exceptions imprévues (de type memory), qui sont susceptible d'intervenir dans un tout petit endroit où on aura oublié (bien évidement) de mettre un Try/Catch (du style un click event).