That seems odd.  Uncaught exceptions in finalizers are
discarded, and maybe there are one or two other such corner
cases, but in the ordinary course of events an uncaught
exception eventually makes its way back to the ultimate
catcher, which dumps whatever stack information is available.
This doesn't depend (as far as I know) on the nature of the
Throwable -- in particular, NullPointerException's stack
trace is not suppressed.

    It sounds like there was a catch-and-ignore somewhere
along the line, in your application or in some framework it
was built around.  That's one reason catch-and-ignore is a
Very Bad Idea.

    You might take a look at the java.lang.instrument package.
I haven't, not seriously, but it seems capable of this sort of
thing.  (It also seems, at a cursory glance, to be considerably
more difficult than inserting println() calls.)  Also, see if
your platform has a DTrace that can see inside Java code -- I
know the Solaris version does, but I'm not sure whether the
other DTrace platforms are as far along.

Many IDE's and debuggers will let you set exception break-points.  They
are much like regular break-points, but pause upon throw of the
particular exception type, rather than on a particular line.

On Fri, 29 Jan 2010 07:22:56 -0800 (PST), Mark Smith
<marksmith5555@jungle-monkey.com> wrote, quoted or indirectly quoted
someone who said :

Problems with stack traces I have include:

1. static init code.  When debugging you can temporarily make it into
instance init code invoked in the constructor.

2. using Jet.  For speed it turns off stack tracing.  You can manually
turn it back on, but it is better just to use HotSpot which is better
suited to debugging.

Perhaps you are not dumping the stack traces properly. See
http://mindprod.com/jgloss/stacktrace.html

e.g. perhaps they are stuck in an unflushed buffer.