Bonjour,
surune application j'utilise une exception applicative
(clsApplicationException qui hérite de ApplicationException) pour gérer
certaines erreurs de l'application. Dans la plupart des cas tout fonctionne
commme prévu, je fais un throw de cette clsApplicationException et je peux la
trapper dans la méthode appelante via un catch(clsApplicationException)
Cependant lorsque la méthode renvoyant l'ApplicationException est appelé via
la reflection, je ne récupére plus l'applicationException. Celle-ci est
encapsulé dans une exception de type
System.Reflection.TargetInvocationException. L'applicationException qui a été
levée est elle accessible via la propriété Innerexception.
Voici un exemple du code:
public class ClasseA {
public static void InvokeMethod( object oObject, string sMethod, object[]
oParam)
{
try
{
Type _type = oObject.GetType();
MethodInfo _method = _type.GetMethod(sMethod);
object _retour = new Object();
//invoque la methode sur l'objet.
if (_method != null )
{
_retour = _method.Invoke(oObject, oparam);
}
Bien que l'application levée dans la méthode invoquée lors du
_method.Invoke(oObject, oparam) soit de type clsApplicationException elle
n'est pas trappé car c'est une System.Reflection.TargetInvocationException
qui est retournée. Pourquoi ce comportement ? Il n'y a aucun catch qui
explique que ce ne soit pas direct-ement la clsApplicationException qui ne
soit pas retourné. Pour le moment je test la propriété innerexception pour
savoir si une clsAppllicationException a été levé mais si dans certains cas
l'exception applicative est encapsulé plus profondement....
Ceci me pose pas mal de problème car j'ai vraiment besoin de ramener des
informations contenue dans l'exception applicative
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Paul Bacelar
C'est ByDesign ;-)
Toutes les exceptions non létal envoyées par des composants sont catchées par les méthodes de réflexion pour permettre une gestion élégante des plug-ins et autres design patterns via des types de.
Si tu veux gérer spécifiquement un type d'exception et que cette exception passe par de la réflexion, il suffit de catcher les exceptions de la couche réflexion (pour un invoke "TargetInvocationException" devrait suffire) et de tester le type de la InnerException. En cas de mauvais type de InnerException, le throw sans paramètre permet de laisser monter l'exception originale.
Si vous implémentez vous même une couche qui doit abstraire le caractère réflexif de vos appels, un throw de la InnerException dans le catch vous permet de cacher l'utilisation de la réflexion. -- Paul Bacelar
"Karl" wrote in message news:
Bonjour, surune application j'utilise une exception applicative (clsApplicationException qui hérite de ApplicationException) pour gérer certaines erreurs de l'application. Dans la plupart des cas tout
fonctionne
commme prévu, je fais un throw de cette clsApplicationException et je peux
la
trapper dans la méthode appelante via un catch(clsApplicationException)
Cependant lorsque la méthode renvoyant l'ApplicationException est appelé
via
la reflection, je ne récupére plus l'applicationException. Celle-ci est encapsulé dans une exception de type System.Reflection.TargetInvocationException. L'applicationException qui a
été
levée est elle accessible via la propriété Innerexception.
Voici un exemple du code: public class ClasseA { public static void InvokeMethod( object oObject, string sMethod, object[] oParam) { try {
Type _type = oObject.GetType(); MethodInfo _method = _type.GetMethod(sMethod); object _retour = new Object();
//invoque la methode sur l'objet. if (_method != null ) { _retour = _method.Invoke(oObject, oparam); }
Bien que l'application levée dans la méthode invoquée lors du _method.Invoke(oObject, oparam) soit de type clsApplicationException elle n'est pas trappé car c'est une System.Reflection.TargetInvocationException qui est retournée. Pourquoi ce comportement ? Il n'y a aucun catch qui explique que ce ne soit pas direct-ement la clsApplicationException qui ne soit pas retourné. Pour le moment je test la propriété innerexception pour savoir si une clsAppllicationException a été levé mais si dans certains
cas
l'exception applicative est encapsulé plus profondement.... Ceci me pose pas mal de problème car j'ai vraiment besoin de ramener des informations contenue dans l'exception applicative
Merci beaucoup de votre aide
C'est ByDesign ;-)
Toutes les exceptions non létal envoyées par des composants sont catchées
par les méthodes de réflexion pour permettre une gestion élégante des
plug-ins et autres design patterns via des types de.
Si tu veux gérer spécifiquement un type d'exception et que cette exception
passe par de la réflexion, il suffit de catcher les exceptions de la couche
réflexion (pour un invoke "TargetInvocationException" devrait suffire) et de
tester le type de la InnerException. En cas de mauvais type de
InnerException, le throw sans paramètre permet de laisser monter l'exception
originale.
Si vous implémentez vous même une couche qui doit abstraire le caractère
réflexif de vos appels, un throw de la InnerException dans le catch vous
permet de cacher l'utilisation de la réflexion.
--
Paul Bacelar
"Karl" <Karl@discussions.microsoft.com> wrote in message
news:D5A3F13C-7997-42BE-AD93-BDAF639E91A7@microsoft.com...
Bonjour,
surune application j'utilise une exception applicative
(clsApplicationException qui hérite de ApplicationException) pour gérer
certaines erreurs de l'application. Dans la plupart des cas tout
fonctionne
commme prévu, je fais un throw de cette clsApplicationException et je peux
la
trapper dans la méthode appelante via un catch(clsApplicationException)
Cependant lorsque la méthode renvoyant l'ApplicationException est appelé
via
la reflection, je ne récupére plus l'applicationException. Celle-ci est
encapsulé dans une exception de type
System.Reflection.TargetInvocationException. L'applicationException qui a
été
levée est elle accessible via la propriété Innerexception.
Voici un exemple du code:
public class ClasseA {
public static void InvokeMethod( object oObject, string sMethod, object[]
oParam)
{
try
{
Type _type = oObject.GetType();
MethodInfo _method = _type.GetMethod(sMethod);
object _retour = new Object();
//invoque la methode sur l'objet.
if (_method != null )
{
_retour = _method.Invoke(oObject, oparam);
}
Bien que l'application levée dans la méthode invoquée lors du
_method.Invoke(oObject, oparam) soit de type clsApplicationException elle
n'est pas trappé car c'est une System.Reflection.TargetInvocationException
qui est retournée. Pourquoi ce comportement ? Il n'y a aucun catch qui
explique que ce ne soit pas direct-ement la clsApplicationException qui ne
soit pas retourné. Pour le moment je test la propriété innerexception pour
savoir si une clsAppllicationException a été levé mais si dans certains
cas
l'exception applicative est encapsulé plus profondement....
Ceci me pose pas mal de problème car j'ai vraiment besoin de ramener des
informations contenue dans l'exception applicative
Toutes les exceptions non létal envoyées par des composants sont catchées par les méthodes de réflexion pour permettre une gestion élégante des plug-ins et autres design patterns via des types de.
Si tu veux gérer spécifiquement un type d'exception et que cette exception passe par de la réflexion, il suffit de catcher les exceptions de la couche réflexion (pour un invoke "TargetInvocationException" devrait suffire) et de tester le type de la InnerException. En cas de mauvais type de InnerException, le throw sans paramètre permet de laisser monter l'exception originale.
Si vous implémentez vous même une couche qui doit abstraire le caractère réflexif de vos appels, un throw de la InnerException dans le catch vous permet de cacher l'utilisation de la réflexion. -- Paul Bacelar
"Karl" wrote in message news:
Bonjour, surune application j'utilise une exception applicative (clsApplicationException qui hérite de ApplicationException) pour gérer certaines erreurs de l'application. Dans la plupart des cas tout
fonctionne
commme prévu, je fais un throw de cette clsApplicationException et je peux
la
trapper dans la méthode appelante via un catch(clsApplicationException)
Cependant lorsque la méthode renvoyant l'ApplicationException est appelé
via
la reflection, je ne récupére plus l'applicationException. Celle-ci est encapsulé dans une exception de type System.Reflection.TargetInvocationException. L'applicationException qui a
été
levée est elle accessible via la propriété Innerexception.
Voici un exemple du code: public class ClasseA { public static void InvokeMethod( object oObject, string sMethod, object[] oParam) { try {
Type _type = oObject.GetType(); MethodInfo _method = _type.GetMethod(sMethod); object _retour = new Object();
//invoque la methode sur l'objet. if (_method != null ) { _retour = _method.Invoke(oObject, oparam); }
Bien que l'application levée dans la méthode invoquée lors du _method.Invoke(oObject, oparam) soit de type clsApplicationException elle n'est pas trappé car c'est une System.Reflection.TargetInvocationException qui est retournée. Pourquoi ce comportement ? Il n'y a aucun catch qui explique que ce ne soit pas direct-ement la clsApplicationException qui ne soit pas retourné. Pour le moment je test la propriété innerexception pour savoir si une clsAppllicationException a été levé mais si dans certains
cas
l'exception applicative est encapsulé plus profondement.... Ceci me pose pas mal de problème car j'ai vraiment besoin de ramener des informations contenue dans l'exception applicative
Merci beaucoup de votre aide
Karl
Merci c'est en effet ce que je fais actuellement
: public class ClasseA { public static void InvokeMethod( object oObject, string sMethod, object[] oParam) { try {
Type _type = oObject.GetType(); MethodInfo _method = _type.GetMethod(sMethod); object _retour = new Object();
//invoque la methode sur l'objet. if (_method != null ) { _retour = _method.Invoke(oObject, oparam); }
return _retour; } catch (ApplicativeExceptionex) { throw new ApplicativeException("Erreur", ex, ex.CodeErreur); } catch (Exception ex) { if (ex.InnerException.GetType().Name.Equals("ApplicativeException")) throw new ApplicativeException("Erreur lors de l'utilisation du reflecter", ex, ((ApplicativeException)ex.InnerException).CodeErreur); else throw ex; } }
Je voulais être sur de ce mécanisme afin d'atre sur que mon exception applicative sera bien toujours accessible via InnerException.
"Paul Bacelar" wrote:
C'est ByDesign ;-)
Toutes les exceptions non létal envoyées par des composants sont catchées par les méthodes de réflexion pour permettre une gestion élégante des plug-ins et autres design patterns via des types de.
Si tu veux gérer spécifiquement un type d'exception et que cette exception passe par de la réflexion, il suffit de catcher les exceptions de la couche réflexion (pour un invoke "TargetInvocationException" devrait suffire) et de tester le type de la InnerException. En cas de mauvais type de InnerException, le throw sans paramètre permet de laisser monter l'exception originale.
Si vous implémentez vous même une couche qui doit abstraire le caractère réflexif de vos appels, un throw de la InnerException dans le catch vous permet de cacher l'utilisation de la réflexion. -- Paul Bacelar
"Karl" wrote in message news: > Bonjour, > surune application j'utilise une exception applicative > (clsApplicationException qui hérite de ApplicationException) pour gérer > certaines erreurs de l'application. Dans la plupart des cas tout fonctionne > commme prévu, je fais un throw de cette clsApplicationException et je peux la > trapper dans la méthode appelante via un catch(clsApplicationException) > > Cependant lorsque la méthode renvoyant l'ApplicationException est appelé via > la reflection, je ne récupére plus l'applicationException. Celle-ci est > encapsulé dans une exception de type > System.Reflection.TargetInvocationException. L'applicationException qui a été > levée est elle accessible via la propriété Innerexception. > > Voici un exemple du code: > public class ClasseA { > public static void InvokeMethod( object oObject, string sMethod, object[] > oParam) > { > try > { > > Type _type = oObject.GetType(); > MethodInfo _method = _type.GetMethod(sMethod); > object _retour = new Object(); > > //invoque la methode sur l'objet. > if (_method != null ) > { > _retour = _method.Invoke(oObject, oparam); > } > > return _retour; > } > catch (clsApplicationException ex) > { > throw new clsApplicationException ("Erreur", ex, ex.CodeErreur); > } > catch (Exception ex) > { > throw ex; > } > } > > Bien que l'application levée dans la méthode invoquée lors du > _method.Invoke(oObject, oparam) soit de type clsApplicationException elle > n'est pas trappé car c'est une System.Reflection.TargetInvocationException > qui est retournée. Pourquoi ce comportement ? Il n'y a aucun catch qui > explique que ce ne soit pas direct-ement la clsApplicationException qui ne > soit pas retourné. Pour le moment je test la propriété innerexception pour > savoir si une clsAppllicationException a été levé mais si dans certains cas > l'exception applicative est encapsulé plus profondement.... > Ceci me pose pas mal de problème car j'ai vraiment besoin de ramener des > informations contenue dans l'exception applicative > > Merci beaucoup de votre aide > > > > >
Merci c'est en effet ce que je fais actuellement
:
public class ClasseA {
public static void InvokeMethod( object oObject, string sMethod, object[]
oParam)
{
try
{
Type _type = oObject.GetType();
MethodInfo _method = _type.GetMethod(sMethod);
object _retour = new Object();
//invoque la methode sur l'objet.
if (_method != null )
{
_retour = _method.Invoke(oObject, oparam);
}
return _retour;
}
catch (ApplicativeExceptionex)
{
throw new ApplicativeException("Erreur", ex, ex.CodeErreur);
}
catch (Exception ex)
{
if (ex.InnerException.GetType().Name.Equals("ApplicativeException"))
throw new ApplicativeException("Erreur lors de l'utilisation du reflecter",
ex, ((ApplicativeException)ex.InnerException).CodeErreur);
else
throw ex;
}
}
Je voulais être sur de ce mécanisme afin d'atre sur que mon exception
applicative sera bien toujours accessible via InnerException.
"Paul Bacelar" wrote:
C'est ByDesign ;-)
Toutes les exceptions non létal envoyées par des composants sont catchées
par les méthodes de réflexion pour permettre une gestion élégante des
plug-ins et autres design patterns via des types de.
Si tu veux gérer spécifiquement un type d'exception et que cette exception
passe par de la réflexion, il suffit de catcher les exceptions de la couche
réflexion (pour un invoke "TargetInvocationException" devrait suffire) et de
tester le type de la InnerException. En cas de mauvais type de
InnerException, le throw sans paramètre permet de laisser monter l'exception
originale.
Si vous implémentez vous même une couche qui doit abstraire le caractère
réflexif de vos appels, un throw de la InnerException dans le catch vous
permet de cacher l'utilisation de la réflexion.
--
Paul Bacelar
"Karl" <Karl@discussions.microsoft.com> wrote in message
news:D5A3F13C-7997-42BE-AD93-BDAF639E91A7@microsoft.com...
> Bonjour,
> surune application j'utilise une exception applicative
> (clsApplicationException qui hérite de ApplicationException) pour gérer
> certaines erreurs de l'application. Dans la plupart des cas tout
fonctionne
> commme prévu, je fais un throw de cette clsApplicationException et je peux
la
> trapper dans la méthode appelante via un catch(clsApplicationException)
>
> Cependant lorsque la méthode renvoyant l'ApplicationException est appelé
via
> la reflection, je ne récupére plus l'applicationException. Celle-ci est
> encapsulé dans une exception de type
> System.Reflection.TargetInvocationException. L'applicationException qui a
été
> levée est elle accessible via la propriété Innerexception.
>
> Voici un exemple du code:
> public class ClasseA {
> public static void InvokeMethod( object oObject, string sMethod, object[]
> oParam)
> {
> try
> {
>
> Type _type = oObject.GetType();
> MethodInfo _method = _type.GetMethod(sMethod);
> object _retour = new Object();
>
> //invoque la methode sur l'objet.
> if (_method != null )
> {
> _retour = _method.Invoke(oObject, oparam);
> }
>
> return _retour;
> }
> catch (clsApplicationException ex)
> {
> throw new clsApplicationException ("Erreur", ex, ex.CodeErreur);
> }
> catch (Exception ex)
> {
> throw ex;
> }
> }
>
> Bien que l'application levée dans la méthode invoquée lors du
> _method.Invoke(oObject, oparam) soit de type clsApplicationException elle
> n'est pas trappé car c'est une System.Reflection.TargetInvocationException
> qui est retournée. Pourquoi ce comportement ? Il n'y a aucun catch qui
> explique que ce ne soit pas direct-ement la clsApplicationException qui ne
> soit pas retourné. Pour le moment je test la propriété innerexception pour
> savoir si une clsAppllicationException a été levé mais si dans certains
cas
> l'exception applicative est encapsulé plus profondement....
> Ceci me pose pas mal de problème car j'ai vraiment besoin de ramener des
> informations contenue dans l'exception applicative
>
> Merci beaucoup de votre aide
>
>
>
>
>
: public class ClasseA { public static void InvokeMethod( object oObject, string sMethod, object[] oParam) { try {
Type _type = oObject.GetType(); MethodInfo _method = _type.GetMethod(sMethod); object _retour = new Object();
//invoque la methode sur l'objet. if (_method != null ) { _retour = _method.Invoke(oObject, oparam); }
return _retour; } catch (ApplicativeExceptionex) { throw new ApplicativeException("Erreur", ex, ex.CodeErreur); } catch (Exception ex) { if (ex.InnerException.GetType().Name.Equals("ApplicativeException")) throw new ApplicativeException("Erreur lors de l'utilisation du reflecter", ex, ((ApplicativeException)ex.InnerException).CodeErreur); else throw ex; } }
Je voulais être sur de ce mécanisme afin d'atre sur que mon exception applicative sera bien toujours accessible via InnerException.
"Paul Bacelar" wrote:
C'est ByDesign ;-)
Toutes les exceptions non létal envoyées par des composants sont catchées par les méthodes de réflexion pour permettre une gestion élégante des plug-ins et autres design patterns via des types de.
Si tu veux gérer spécifiquement un type d'exception et que cette exception passe par de la réflexion, il suffit de catcher les exceptions de la couche réflexion (pour un invoke "TargetInvocationException" devrait suffire) et de tester le type de la InnerException. En cas de mauvais type de InnerException, le throw sans paramètre permet de laisser monter l'exception originale.
Si vous implémentez vous même une couche qui doit abstraire le caractère réflexif de vos appels, un throw de la InnerException dans le catch vous permet de cacher l'utilisation de la réflexion. -- Paul Bacelar
"Karl" wrote in message news: > Bonjour, > surune application j'utilise une exception applicative > (clsApplicationException qui hérite de ApplicationException) pour gérer > certaines erreurs de l'application. Dans la plupart des cas tout fonctionne > commme prévu, je fais un throw de cette clsApplicationException et je peux la > trapper dans la méthode appelante via un catch(clsApplicationException) > > Cependant lorsque la méthode renvoyant l'ApplicationException est appelé via > la reflection, je ne récupére plus l'applicationException. Celle-ci est > encapsulé dans une exception de type > System.Reflection.TargetInvocationException. L'applicationException qui a été > levée est elle accessible via la propriété Innerexception. > > Voici un exemple du code: > public class ClasseA { > public static void InvokeMethod( object oObject, string sMethod, object[] > oParam) > { > try > { > > Type _type = oObject.GetType(); > MethodInfo _method = _type.GetMethod(sMethod); > object _retour = new Object(); > > //invoque la methode sur l'objet. > if (_method != null ) > { > _retour = _method.Invoke(oObject, oparam); > } > > return _retour; > } > catch (clsApplicationException ex) > { > throw new clsApplicationException ("Erreur", ex, ex.CodeErreur); > } > catch (Exception ex) > { > throw ex; > } > } > > Bien que l'application levée dans la méthode invoquée lors du > _method.Invoke(oObject, oparam) soit de type clsApplicationException elle > n'est pas trappé car c'est une System.Reflection.TargetInvocationException > qui est retournée. Pourquoi ce comportement ? Il n'y a aucun catch qui > explique que ce ne soit pas direct-ement la clsApplicationException qui ne > soit pas retourné. Pour le moment je test la propriété innerexception pour > savoir si une clsAppllicationException a été levé mais si dans certains cas > l'exception applicative est encapsulé plus profondement.... > Ceci me pose pas mal de problème car j'ai vraiment besoin de ramener des > informations contenue dans l'exception applicative > > Merci beaucoup de votre aide > > > > >
