Home of the ColdFusion Community
|
Mailing Lists
|
Home /
Groups /
ColdFusion Talk (CF-Talk)
Why throw exceptions (was RE: CFC's and Returns)
Author: Tony Weeg
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:23952#120490
good stuff sean. thanks for the insight. and oddly enough
it all made sense...even to me, a cf non-c++/java and hardly
starting ecma anything ;)
tony
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
Author: Kwang Suh
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:23952#120489
Somehow I knew that you'd explain the whole thing :)
----- Excess quoted text cut - see Original Post for more -----
Author: Sean A Corfield
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:23952#120487
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
Author: Kwang Suh
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:23952#120484
> I guess you want speed when everything succeeds, but if there's a failure
it
> doesn't matter if the code is slower as the error will probably stop the
> action anyway. So at first appearance it seems like cftry should speed
> things up as the decision making code is reduced.
I don't think it matters in Java/CFMX. I haven't seen too much debate about
this in regards to Java.
>
> Is there some reason why cftry (or try{} or whatever it is in C++) might
> slow things down?
It's one of those uber-nerd things :)
>
> > 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
----- Excess quoted text cut - see Original Post for more -----
Previously
----- Excess quoted text cut - see Original Post for more -----
you
----- Excess quoted text cut - see Original Post for more -----
http://java.sun.com/docs/books/tutorial/essential/exceptions/definition.ht
----- Excess quoted text cut - see Original Post for more -----
as
----- Excess quoted text cut - see Original Post for more -----
strings,
----- Excess quoted text cut - see Original Post for more -----
different
----- Excess quoted text cut - see Original Post for more -----
to
> > do
> > > > with them. If the application fails the UI knows why and
what to
tell
----- Excess quoted text cut - see Original Post for more -----
probably
----- Excess quoted text cut - see Original Post for more -----
called
----- Excess quoted text cut - see Original Post for more -----
with
----- Excess quoted text cut - see Original Post for more -----
As
----- Excess quoted text cut - see Original Post for more -----
Author: Matthew Walker
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:23952#120483
Apologies for my previous msg btw - it looks like I left half a sentence
out.
I guess you want speed when everything succeeds, but if there's a failure it
doesn't matter if the code is slower as the error will probably stop the
action anyway. So at first appearance it seems like cftry should speed
things up as the decision making code is reduced.
Is there some reason why cftry (or try{} or whatever it is in C++) might
slow things down?
----- Excess quoted text cut - see Original Post for more -----
Author: Kwang Suh
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:23952#120481
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.
> I found this page (which is about java but it applies equally to CF)
really
> thought-provoking and I intend to use exceptions a lot more. Previously I
> had considered them something to avoid. But I can see that you can use
them
> as a more elegant tool.
>
> The key concept I took from this article is that by using exceptions you
can
> save your elegant code from being cluttered up with handling for edge
cases.
>
>
>
http://java.sun.com/docs/books/tutorial/essential/exceptions/definition.html
----- Excess quoted text cut - see Original Post for more -----
the
----- Excess quoted text cut - see Original Post for more -----
am
----- Excess quoted text cut - see Original Post for more -----
Author: Matthew Walker
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:23952#120480
I found this page (which is about java but it applies equally to CF) really
thought-provoking and I intend to use exceptions a lot more. Previously I
had considered them something to avoid. But I can see that you can use them
as a more elegant tool.
The key concept I took from this article is that by using exceptions you can
save your elegant code from being cluttered up with handling for edge cases.
http://java.sun.com/docs/books/tutorial/essential/exceptions/definition.html
> That's what I do.. return a struct that is.. I tend to think of it as a
> status object.
>
> status.success = true / false;
> status.description = "description";
> status.result = result; // your expected return.. recordset, strings,
etc..
----- Excess quoted text cut - see Original Post for more -----
|
May 24, 2012
|
Latest Fusion Authority Articles
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
