UnsatisfiedLinkError and stracktraces

[Tom Rodriguez]

> 1. Is there somewhere a specification of what methods need to be in the
> stacktrace?  Would it also be OK to print something like this:
> 
> java.lang.UnsatisfiedLinkError: nsub
>         at java.lang.Throwable.fillInStackTrace(Native Method)
>         at java.lang.Throwable.<init>(Throwable.java:214)
>         at java.lang.Error.<init>(Error.java:67)
>         at java.lang.LinkageError.<init>(LinkageError.java:54)
>         at java.lang.UnsatisfiedLinkError.<init>(UnsatisfiedLinkError.java:53)
>         at extest.nsub(Native Method)
>         at extest.main(extest.java:336)

I don't think there's a specification of what should be in a stack trace other 
than the vague language that they are precise.  The standard logic we use for 
recording stack traces skips the exception constructor frames since they're 
really just noise.  I think some printing functions for chained exceptions will 
only dump a few frames of the stack trace and wasting five of them may make 
those printouts less useful.  With the Throwable.getStackTrace API it's possible 
to programmatically inspect trace information which could conceivably expose 
differences between implementations but that seems like stretch.

> 2. What is the reason the failing native method is in the stacktrace?
> Actually it isn't called.  I guess it's something about the way native
> methods are called in HotSpot (e.g. native stubs).  Would this be OK
> too:
> 
> java.lang.UnsatisfiedLinkError: extest.nsub()V
>         at extest.main(extest.java:336)

I believe that at the point we throw it we've already pushed a frame for the 
native method so we could start invoking it and then we discover that we can't 
link it which is why it shows up in the call stack.  I can't think of any reason 
why one would be preferred over the other.

tom