House of Fusion
Search over 2,500 ColdFusion resources here
  
Home of the ColdFusion Community

Mailing Lists
Home / Groups / ColdFusion Talk (CF-Talk)

Why throw exceptions (was RE: CFC's and Returns)

Author:
Sean A Corfield
05/14/2003 10:49 PM

On Wednesday, May 14, 2003, at 19:05 US/Pacific, Kwang Suh wrote: > Even today, there's lots of debate in the C++ universe about whether > throwing exceptions and using try/catch is too slow, which is where a > lot of > the avoidance of using exceptions comes from. As someone who was involved in the design of C++, I'll give some background on this... Originally, C++ had no exceptions. Bjarne had proposed them in the ARM (Annotated Reference Manual) but there were no implementations and no 'definitive' document about how they worked. During the C++ standardization process, we refined the definition of how exceptions should work and various compiler vendors who participated in the standards process tried various implementations. The goal was that there should be zero performance overhead if your code never threw an exception. That turned out to be harder than you might imagine because every try/catch block has to dynamically lay down some information in the call stack just in case an exception is thrown and the system has to unwind the call stack looking for a catch that can handle that exception. But, eventually, vendors got pretty close. Smart folks. Now let's turn to the actual exception throwing and catching process. Throwing an exception starts off a process of walking up the call stack (and, in fact, even the dynamically nested block scope stack) trying to find active catch handlers. As it goes, it has to unwind the stack and destroy any declared variables. When it finds a catch handler, it has to check the dynamic type of the handler to see whether it is compatible (e.g., throw an int and catch it with a long; throw a derivedObject and catch it was a BaseClass - assuming derived inherits from base). That's just plain old expensive. And then you have what's called the exception-specification on function definitions where you say this function can throw exception X. That introduces *implicit* catch handlers that catch & rethrow the declared exceptions but catch & fail on any other exceptions (in fact it can throw an "unhandled exception" exception!). By now, you should have some idea why exceptions are considered bad / expensive in C++!! Now let's turn to Java. First of all, Java checks exception safety at *compile* time, not runtime. That allows it to do a lot of optimization (in fact, one of the first post-ISO-Standard modifications to C++ being discussed was tightening the exception model to match Java!). Secondly, Java doesn't force object destruction when the end of a block is encountered - Java only destroys objects when the garbage collector runs. That means that the stack unwinding required to catch an exception doesn't have the additional overhead of destroying all the transients objects (which C++ has). So, exception handling in Java is simply not as expensive - in principle - as it is in C++. That leads to a different mindset about exceptions (Exceptions Good). Finally, let's turn to CF. CF doesn't have the nested scopes that either C++ or Java have so that's one simplification. CF doesn't have exception-specifications (on functions) so there is no implicit try/catch machinery. CF also doesn't have the same exception type catch checking that C++ or Java has - a CF exception has a type which is a string and the catch handler catches by name or partial name (throw type="a.b.c" and you can catch it with type="a" or type="a.b"). That means that conceptually CF has less overhead with exceptions that even Java has. So, we should consider Exceptions Good in ColdFusion! p.s. thanks for reading through all the technical stuff about C++ and Java to get to this CF nugget... Sean A Corfield -- http://www.corfield.org/blog/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood


Search cf-talk

October 02, 2014

<<   <   Today   >   >>
Su Mo Tu We Th Fr Sa
       1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31   

Designer, Developer and mobile workflow conference