DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16770>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16770 JAMES silently consumes java.lang.Error thrown by Maillet.service() ------- Additional Comments From [EMAIL PROTECTED] 2003-02-04 23:55 ------- Ah, superb timing. You are right of course about the inaccuracy in my description, in all cases by "JAMES" I meant "JAMES or one of the components upon which it depends". I have not yet looked deeply enough to make sense of what Excalibur is or does. (I'll do so later.) Given that it is Excalibur's WorkerThread that is silently consuming java.lang.Error, then it might be reasonable to report the bug there (I don't yet know enough to do this). Given that inserting a workaround into JAMES gets JAMES clear of this bug, then I'm all for it of course. At the risk of teaching you to suck eggs, I'll point out that, if you are going to catch java.lang.Error, then a not-unreasonable response is System.exit(). This is because java.lang.Error and its decendants are generally used to signify problems that represent a breach of the Java type system (e.g. out of memory, classes missing, signatures altered incompatibly, etc.), in roughly the same sense that a kernel panic does in an operating system. That Java allows you a chance to clean up (by throwing an Error instead of aborting immediately) is a deliberate feature, however using it to keep a broken type system running indefinitely may introduce further problems. Most seriously, if a type system breach leaves a SecurityManager in an inconsistent state (e.g. out of memory leading to failed allocation of an object during the updating of a linked list of credentials), then by catching Error and not aborting the JVM, you've provided a vulnerability through which an adversary may breach access control, confidentiality or integrity constraints. Better to reduce availability and allow an adversary to bring about a denial of service (by tickling a bug which aborts the JVM) than to open a potentially serious hole. IMHO. {{ Lecture ends :-) }} --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
