We are executing a J# instance method via reflection that
causes an exception to be thrown. The reflection API
throws an InvocationTargetException however the details of
the original exception contained within the
InvocationTargetException and the StackTrace are null.

This appears to be a similar problem that Brien posted to
this newsgroup on 2002-10-24 13:54:08.

Gopinath (MS) responsed on 22-10-30 22:34:05 stated that
there appeared to be a bug in J# "that the stack trace is
not getting set properly".

Can you confirm if this "bug" was fixed in any release of
J# or the .Net Framework

As Brien stated, providing accurate debugging information
is critical to any IDE.

If you someone could provide an update on the status of
this problem it would be very helpful

Dylan

It is probably because the exception that gets thrown by the method is a non
Java exception (an exception that derives from System.Exception but not from
java.lang.Throwable). The problem is that the getTargetException() method
returns a java.lang.Throwable, and it cannot be used to return a non Java
exception, so the J# designers have decided to return null in this case.

I signaled this problem a long while ago, and it really needs attention
because it prevents you from using the Java reflection API if you want to be
able to log all exception stacktraces in a reliable way (because of that, we
had to switch to the .NET reflection API, which caused other annoyances,
like having to box primitive types the .NET way rather than the Java way).

There a few ways J# could solve this without breaking Java specs (they
cannot change the return type of getTargetException). For example, there
could be an additional method like getDotNetTargetException() that returns a
System.Exception, or J# could use a wrapper class that wraps a
System.Exception into a java.lang.Exception, and getTargetException could
return the wrapped exception.

Another annoyance is that J# treats .NET exceptions as checked exceptions
(you have to declare them in your throws clause), which is at odds with the
way C# (and other .NET languages) treat .NET exceptions.

Bruno.

"Dylan" <dylan.hayes (AT) bearingpoint (DOT) com> a écrit dans le message de news:
08ee01c4ac4e$cebd1020$a301280a (AT) phx (DOT) gbl...