www.digitalmars.com         C & C++   DMDScript  

D - Exceptions in Green

reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
Hype of the Day:

Green is an object-oriented, statically typed research language with
C/Pascal hybrid syntax and a couple of interesting features such as
metaclasses and some kind of reflection mechanism. I didn't have time to
delve into the details of the language quite yet; what caught my
intention was the unusual exception mechanism, which is described in

http://www.dc.ufscar.br/~jose/green/articles/tgles.pdf

The general idea is to remove traditional procedural exception handlers
with object-oriented "catch objects".

Quote:

"Modularity is the property that makes it easy to change a piece of code
(module/class/method) without invalidating other module or class that
uses it. Exception handling systems of Java/C++ are harmful to
modularity because changes in the exception class hierarchy or in
methods that signals exceptions may require changes in the treatment of
the exceptions, which are spread throughout the code in catch clauses
that follow try statements."

The language's web page can be found at

http://www.dc.ufscar.br/~jose/green/green.htm

(Wonder if someone posted about it earlier?)

-Antti
Aug 30 2003
parent reply "Jeroen van Bemmel" <someone somewhere.com> writes:
 (Wonder if someone posted about it earlier?)

Hmm, probably not. I wonder why... Seriously, without getting too negative here, this 'Green language' does not really solve anything. They claim that exception handling in Java/C++ is flawed because "it is not object oriented" and (thus) "you cannot reuse the handlers". "[...] the exception systems of many object-oriented languages are procedural in nature because the catch clauses following a try block act like procedures. These systems benefit from very few features of object-oriented programming." 1) "Being object oriented" is not a goal but a means. Something is not better or worse just because it is OO or not, it is perhaps different. It seems to be popular just because OO is often associated with 'modern', 'state of the art', 'dynamic', etc "It's OO? Oh, then it must be good..." 2) Reusing handlers does not seem like a real-life issue to me. Did they investigate how many opportunities the average program has to reuse exception handlers? Probably not, because then they would have found that most of the time the place where an exception gets thrown affects how it is handled and what needs to be done next (duh). 3) Allocating a new exception handler object for each 'try' clause is a major waste of resources, especially since exceptions should be the exception and not the rule and 4) Green is not a language, but a code generator that copies most of its input to its output except for the exception clauses And don't get me started on "dynamically replacing catch handlers" ...
Sep 02 2003
next sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
ONERR GOTO 505 : GOSUB TRYTHIS

"Jeroen van Bemmel" <someone somewhere.com> wrote in message
news:bj32ll$dna$1 digitaldaemon.com...

 And don't get me started on "dynamically replacing catch handlers" ...

Sep 02 2003
prev sibling parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
 2) Reusing handlers does not seem like a real-life issue to me. Did they
 investigate how many opportunities the average program has to reuse
 exception handlers? Probably not, because then they would have found that
 most of the time the place where an exception gets thrown affects how it

 handled and what needs to be done next (duh).

Reusing handlers is something important to allows matching error handling between module written with different compilers (or even version of the same one) or libraries that are not using the same error handling model. On simple example is COM programming where all errors are returned as an HRESULT (a 32 bit integer) and extra error information is stored in an object that support IErrorInfo interface. If not the same compiler is used or if calls are remote, then it is very important to properly handle errors. In C++, there was a way to handle exceptions the same way. Essentially, it require to do something like: void decode_exceptions() { try { throw; // rethrow last exception } catch (CException *x) { // do something... } catch (std::exception const &x) { // do something... } catch (...) { // do something with any unknown errors.... } } and use it that way: try { something(); } catch (...) { decode_exceptions(); } In COM programming, we would have return the appropriate error code and set the error information object... Another thing that would be important to define is how the language handled system exceptions (access violation, stack overflow, flotting-point errors,...). I think that having the possibility to handle exceptions by some classes would be very interesting. And also the possibility to add pre or post handler. Maybe pre-handler could allows resuming execution for some kind of (system) errors... Here is an exemple of exception handler class: exception_handler class XHandler { public: void catcher(except1 x) { some code... } void catcher(except2 x) { some code... } void catcher(except3 x) { some code... } private: void some_helper_functions(args a) { ... } } To uses it, it would typically be a modified catch statement... but it might also be possible to install pre and post handler... A pre-handler would be execute first. Eventually we might have some control on the order (add in front or back of pre-handler)
Sep 03 2003
parent "Jeroen van Bemmel" <someone somewhere.com> writes:
 Reusing handlers is something important to allows matching error handling
 between module written with different compilers (or even version of the
 same one) or libraries that are not using the same error handling model.

 On simple example is COM programming where all errors are
 returned as an HRESULT (a 32 bit integer) and extra error
 information is stored in an object that support IErrorInfo interface.

 If not the same compiler is used or if calls are remote, then it
 is very important to properly handle errors.

 In C++, there was a way to handle exceptions the same way.
 Essentially, it require to do something like:

 void decode_exceptions()
 {
     try {
         throw;    // rethrow last exception
     } catch (CException *x) {
         // do something...
     } catch (std::exception const &x) {
         // do something...
     } catch (...)
     {
         // do something with any unknown errors....
     }
 }

 and use it that way:

 try {
     something();
 } catch (...) {
     decode_exceptions();
 }

OK, so there are cases where you might want to reuse handlers. An example would be if you are translating exceptions from one system to another, e.g. from Java exceptions to SOAP faults or COM errors to C++ exceptions as in your example. As your example shows, you don't need objects or classes for this, a simple try { ... } catch (std::exception const &e) { ::reused_handler( e ); } would suffice. True, you could put it in some class as a static member function, you might even put it in an object as a normal member function. My point remains that it does not matter if you do it in an 'OO way' or a 'procedural way', the problem or goal is to reuse a handler and a solution is to put the handler code in a function and call it. The paper would have been better if they had found and explained a proper use case for the solution they propose, like you do. "Currently it is not OO, and it should be OO" is not good enough
Sep 03 2003