Discussion :

[Mickael Baron]

Bonjour,

Je préviens je débute en C#.

Je souhaite intercepter une exception via un bloc try catch. Si mon application est en mode debug et si mon exception est déclenchée, le bloc catch l'intercepte et le traitement associé est réalisé.

Toutefois, si mon application est en mode release (l'application est déployée) et si mon exception est déclenchée, Windows prend donc la main (une boîte de dialogue apparait avec un message de type Unhandled exception) sur mon application et mon bloc catch ne l'intercepte pas, alors qu'il devrait.

Ma question est la suivante:
Comment désactiver le fait que Windows puisse prendre la main quand il y a ce genre de problème.

Merci d'avance
Mickael

[Sphax]

Salut,

Un try/catch doit fonctionner de la même manière en debug et release (tu parles bien de compilation debug et release, pas d'appli lancée avec un debugger ou pas ?). On peut voir à quoi ressemble ton catch ? Il se peut qu'en release ce ne soit pas la même exception qui est lancée ?

Comment désactiver le fait que Windows puisse prendre la main quand il y a ce genre de problème.

Pour tte exception non gérée par ton appli, windows prendra forcement la main. Selon le type de ton appli (console, winform, asp.net) tu peux aussi t'abonner auprès d'évènements qui sont levés qd une exception non gérée se produit (voir ici).

[harz62]

Dans les 2 cas que ce soit une compilation en mode débug ou en mode release, ça passe par le CLR pour la sécurité (normal sinon à quoi servirait-t-il ?). Pour ce qui est des exceptions, normalement il devrait les rattraper, Windows lui n'a jamais la main sur une exception .NET car elle est toujours gérée par le CLR, c'est peut être dû à un paramètre de compilation.

[Sphax]

Certes c'est .Net qui cherche dans un premier temps un gestionnaire d'exception managé mais qd il n'en trouve pas toute exception est remontée au niveau au dessus: windows (enfin sauf dans le cas d'une appli asp.net heureusement et peut-être dans certain cas particuliers). Et même si ce n'est pas windows, par ce que je ne maîtrise pas ce qui se passe exactement à ce niveau, c'est au moins un gestionnaire "global" d'exception du CLR qui prend la main et qui termine l'application, ce qui revient au même.

[smyley]

Juste comme ça ...
Pourrais-tu donner un exemple de code où tu penses que le catch n'est pas atteint et le type d'exception levée ?

[Mickael Baron]

Bonjour à tous et merci pour les réponses,

Je viens de re-faire le bout de code de la manière à l'isoler dans une simple application et tout va bien.

Voici le petit bout de code

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
private void button1_Click(object sender, EventArgs e) {
 string aWebServiceAnswer;
 string aXmlFile = "<WEB_SERVICE OPERATION=\"LANGUES\"><SECURITY></SECURITY></WEB_SERVICE>";
 try {
  //Creation d'un instance du service
  localhost.DataEnvironnementService webServicesData = new localhost.DataEnvironnementService();
 
  //Appel d'un service
  aWebServiceAnswer = webServicesData.getLanguages(aXmlFile);
 
  //Affichage de la réponse
  textBox1.Text = aWebServiceAnswer;
 } catch (Exception ex) {
  MessageBox.Show("Erreur avec le web service \n\r" + ex.Message);
 }
}

En y réfléchissant par rapport au problème initial, le souci vient peut être du fait que l'appel à ce petit bout de code (qui génère l'exception) se fait à partir d'un thread. Ainsi, dans ce cas, ça ne passe pas.

Mickael

[Sphax]

Les appels à des contrôles depuis un autre thread que le thread propriétaire de ces contrôles est à proscrire. Et le comportement de ce code peut changer selon que tu sois en degug/release ou avec un debugger attaché. Tu peux voir une explication sur la bonne manière de faire les choses ici.
Et je n'en suis pas sûr mais peut-être que l'appel à MessageBox.Show peut poser un problème depuis un thread qui n'a pas de file de message associée (mais je m'avance un peu là). Ce qui fait que dans ton catch tu pourrais lever une autre exception.

[smyley]

Et je n'en suis pas sûr mais peut-être que l'appel à MessageBox.Show peut poser un problème depuis un thread qui n'a pas de file de message associée (mais je m'avance un peu là). Ce qui fait que dans ton catch tu pourrais lever une autre exception.

Je ne crois pas, le seul problème que j'ai pu voir avec les MessageBox c'est que si on les lance dans un finaliseur (~laclasse()) elle ne reste pas affichée longtemps car le CLR kill les finaliseurs qui prennent du temps ...

Au fait tu pourrai essayer de rajouter un handler dans AppDomain.UnhandledException pour voir ...

[Mickael Baron]

Bonjour à tous,

Comme écrit plus haut, je débute dans la plateforme .NET. Venant du monde Java, j'essaye de faire le parallèle pour résoudre le problème.

Dans le cas de la boîte à outils graphique SWT, quand des éléments graphiques sont modifiées il faut passer par le thread qui gère la couche graphique appelée ThreadUI. Dans le cas contraire une exception système est déclenchée.

Je me demandais si ça ne pouvait pas être la même chose.

Mickael

[tomlev]

Oui, c'est le même principe. Il faut utiliser la méthode Invoke de la form pour exécuter une méthode sur le thread de la Form.

[smyley]

Sinon on ne le fait pas on obtient une InvalidOperationException avec comme message "Cross-thread operation not valid" ... cependant si je me souvient bien cette erreur n'est lancée en général que si le debugger est attaché au processus ...
Plus d'informations sur ce comportement sont disponibles ici