Of course, if we want to get _really_ esoteric, then all the exception table searching and popping back to new PC locations is likely to be slowly executed on a state-of-the-art processor, as these unpredictable jumps will play havoc with the processor instruction pipelines...
----- Original Message ----- From: "Galbreath, Mark" <[EMAIL PROTECTED]> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> Sent: Wednesday, January 30, 2002 7:01 PM Subject: RE: Basic (esoteric) Question > 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 > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
