Discussion :

[anthyme]

Bonjour!

Je ne sais pas si certains d'entre vous utilisent beaucoup la réflexion mais si il y en a qu'ils se montrent

Je vous explique mon soucis :

j'utilise assez souvent cette méthode :

Code :

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

MethodInfo.Invoke(object, object[])

Mais lorsque le code appelé génère une exception - dans une des méthodes écrites dans mon projet - le debugger m'indique que l'exception vient de la ligne de l'appel via réflexion et non pas la ligne effective d'où vient l'exception (un peu comme lorsque l'on appel une methode d'une dll ou du Fx).

C'est assez embêtant pour déboguer l'appli ... est ce que l'on peut contourner cette limitation ?

Merci

[tomlev]

la InnerException contient pas plus d'infos ?

[SaumonAgile]

Et c'est quoi l'exception ?

[anthyme]

L'exception qui est une TargetInvocationException contient une InnerException contient bien l'exception original.

Par exemple is dans le code appelé je fais un

Code :

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

throw new IOException("kikoo");

C'est bien cette exception la qui est dans la inner exception.

Le problème est que le debugger m'indique l'exception à l'endroit ou la TargetInvocationException a eu lieu pas la IOException.

Si on imagine que j'appel du code via reflexion qui appel du code a moi qui appel du code a moi et qui leve une exception de type "NullReferenceException" et bien pour la retrouver je suis vraiment mal barré !

En plus je créé un "mini framework" (enfin ca fait 15 lignes ) qui me permet de faire de la reflexion avec un code de ce type :

Code :

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

monObjet.Methods()["NomDeLaMethode"].Call();

donc dés que je fait ma reflexion en passant par ce tuyau toutes les exception qui pourrais y avoir dans le code appellé ammenne le debugger dans la methode "Call" ... est ce que je ne peux pas dire au debugger "d'aller voir ailleurs" ou d'ignorer la "TargetInvocationException".

Ce qui me frustre c'est que dans la page asp.net généré (qui contient l'erreur) j'ai ceci :

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
Server Error in '/' Application.
kikoo
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
 
Exception Details: System.IO.IOException: kikoo
 
Source Error:
 
Line 26:             throw new IOException("kikoo");
 
 
Stack Trace:
 
[IOException: kikoo]
   MyProject.UI.Logic.Presenters.TestPresenter.OnLoaded() in d:\Documents and Settings\acaillard\Mes documents\Projets\MyProject\MyProject.UI.Logic\Presenters\TestPresenter.cs:26
   MyProject.UI.Logic.Presenters.Presenter`1.Load(T view) in d:\Documents and Settings\acaillard\Mes documents\Projets\MyProject\MyProject.UI.Logic\Presenters\Presenter.cs:115
 
[TargetInvocationException: Exception has been thrown by the target of an invocation.]
   System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner) +0
[...]

Donclui il detecte bien qu'il faut aller a cette exception et me montre bien la bonne ligne ! si il le fait VS doit pouvoir le faire !

[SaumonAgile]

Deux solutions :
- tu actives le break lors du déclenchement des exceptions (dans la fenêtre Debug -> Exceptions)
- tu débogues à la main et tu fais F11 sur le Invoke pour arriver dans la méthode invoquée et voir où se trouve l'erreur.

[tomlev]

Si tu es en debug, tu dois avoir le numéro de ligne dans la stacktrace de la InnerException, non ?

[anthyme]

Si tu es en debug, tu dois avoir le numéro de ligne dans la stacktrace de la InnerException, non ?

Il y a une différence de productivité entre le debugger qui t'indique la ligne et lire les stacktrace (sinon je vais retourner faire du java 1.1 )

Deux solutions :
- tu actives le break lors du déclenchement des exceptions (dans la fenêtre Debug -> Exceptions)
- tu débogues à la main et tu fais F11 sur le Invoke pour arriver dans la méthode invoquée et voir où se trouve l'erreur.

Je vais regarder cette histoire de break, merci

[tomlev]

Il y a une différence de productivité entre le debugger qui t'indique la ligne et lire les stacktrace

Certes... mais c'est déjà mieux que de pas savoir du tout où ça a planté