Caldarale, Charles R schrieb am 19.11.2008 um 19:45:37 (-0600): > > > Try/catch can't be that much of a problem, can it? Isn't it > > just a fancy way of conditional branching with information > > attached? > > Sorry, but no. The throwing of an exception causes the current block > to terminate abruptly and transfer control to JVM-generated code that > searches a catch block table for the address of the failure, and then > does further searches looking for a matching exception type. If no > match is found, the current stack frame is popped off, and the process > repeats with the calling method's catch block table. Although modern > JITs are better at doing this than pre-HotSpot ones, it's still a lot > more expensive than a simple test.
Thanks a lot for this clarification. I was unaware of this. It seems to have been true for more than eight years ... Well, probably since Java's inception. Exceptions in Java: Nothing exceptional about them - JavaWorld http://www.javaworld.com/javaworld/jw-08-2000/jw-0818-exceptions.html (pages 4 and 5 on the performance aspect) In short, expending the Java VM to handle a thrown exception requires more effort, i.e., abrupt method completion is significantly more expensive (performance-wise) than a normal method completion. So Christopher's suggestion to add method and property to detect which one of getWriter() and getOutputStream() was called makes sense for situations where I have many nested filters and have them all detect the PW/SOS issue by calling my method in order to avoid risking an exception. Michael Ludwig --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
