Thanks, David...very interesting. Too often, I think, Java programmers take error handling for granted and do not think past the compiler objecting to an unhandled possible error condition by insisting that the exception be thrown or caught. I think it's clear that the decision to declare an exception thrown in the method signature is much less costly than a try-catch-throw new block. And I'd be willing to bet even fewer consider alternative error handling than the try-catch block. It's clear this can have a major impact of the performance of an application.
This just came into my head as I was sitting here coding yesterday morning. I turned to several of my colleagues and asked if anyone knew the performance ramifications of throws vs. try-catch and no one did. Looking at the Java exception handling mechanism from the JVM level is fascinating. Mark -----Original Message----- From: David Hamilton [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 30, 2002 5:28 AM To: Struts Users Mailing List Subject: Re: Basic (esoteric) Question Mark, >From what Bill Venners says in 'Inside the Java2 Virtual Machine', the handling sequence goes like this: The JVM searches the class exception table for an entry that included the current program counter (PC) location. If found the associated handler is called. If not entry is found, the top frame is popped off the stack, and the search is repeated for the newly current PC location. Popping the stack will have minimal overhead (since it occurs at the end of every method call). This suggests that the overhead of throwing an exception will be * Cost of object creation of exception * Cost of searching the exception tables (proportional to the number of exception handlers in the class X number of methods between thrower and catcher) I don't know what the relative contribution of these parts would be, but my guess would be that the object creation overhead would generally (VM dependant of course) be noticeably greater. [Second bit assumes all methods are in the same class - but the principle is similar across many classes] As an aside, a quick quote from a JavaWorld article on performance: "Since exception handling shouldn't be done on a speed-critical path, this doesn't bother me and I haven't benchmarked it." I.E. Exceptions should be used to handle exceptional conditions (non-standard program flows). If this is part of your standard program flow, you should probably be looking at a rework to return an error code rather than throwing an exception. david ----- Original Message ----- From: "Galbreath, Mark" <[EMAIL PROTECTED]> To: "Servlets (E-mail)" <[EMAIL PROTECTED]>; "J2ee (E-mail)" <[EMAIL PROTECTED]>; "Struts (E-mail)" <[EMAIL PROTECTED]> Sent: Tuesday, January 29, 2002 4:46 PM Subject: Basic (esoteric) Question > Does anybody know of any design considerations that would affect the > performance of a method that declares a <throws> in its signature vs. an > exception that is either caught or thrown new in the <try-catch> block? > > Mark > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
