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


is

 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