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

> (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" ...

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

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

> 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