Details
-
Bug
-
Status: Closed
-
Resolution: Fixed
-
2.1
-
None
-
None
-
Operating System: Other
Platform: Other
-
16770
Description
A java.lang.Error indicates a catastrophic, unrecoverable failure for the JVM
itself. It should never be caught, the JVM should be allowed to abort.
For application servers that absolutely insist on attempting to continue to
provide uninterrupted service for other components when one component
experiences such a condition, the error should at the very least be reported to
the administrator and the component marked as offline; silently consuming a
java.lang.Error is Very Bad; continuing to attempt to stuff requests through a
failed component is Extraordinarily Bad.
Catching Throwable is Really Quite Bad.
My particular problem arose from having an error in my build.xml which meant
that a jar needed by the maillet was missing which meant that a
java.lang.NoClassDefFoundError was thrown during class loading while servicing
the first request. JAMES decided to pretend that the Error had not happened and
(a) not log it anywhere then (b) continue to stuff requests through the failed
component. It wasn't until I decided to investigate why multiple threads
appeared to be occupying the same synchronized block that I realised that
something other than an Exception was being thrown and that JAMES was concealing it.
If you're going to try to catch anything more than Exception, then PLEASE handle
them sensibly.
Oh, how to reproduce:
public void service(Mail mail)
{ throw new Error(); }Then notice the complete absence of logging, stdout or stderr clues about what
has happened.