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)

  << Previous Post |  RSS |  Sort Oldest First |  Sort Latest First |  Subscribe to this Group Next >> 
Top  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
Matthew Walker
05/14/2003 09:29 PM

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 -----

Top  |   Parent  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
Kwang Suh
05/14/2003 10:11 PM

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 -----

Top  |   Parent  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
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

Top  |   Parent  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
Kwang Suh
05/14/2003 11:00 PM

Somehow I knew that you'd explain the whole thing :) ----- Excess quoted text cut - see Original Post for more -----

Top  |   Parent  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
Tony Weeg
05/14/2003 11:01 PM

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

Top  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
Matthew Walker
05/14/2003 10:18 PM

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 -----

Top  |   Parent  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
Kwang Suh
05/14/2003 10:21 PM

> 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 -----


<< Previous Thread Today's Threads Next Thread >>

Search cf-talk

August 22, 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