RE: [boost] Re: Filesystem library: remove / etc

From: Glew, Andy (andy.glew_at_[hidden])
Date: 2002-03-20 17:23:02

> There are two reasons to use a return code approach: the 
> error is benign and needing to know about it is rare.

These are the following basic error handling techniques:
(1) exceptions
        - errors are rare, and should not be ignored
        - performance loss when errors are handled okay
                (since most C++'s do exceptions slowly)
(2) return code
        - errors are common
        - performance loss on error not acceptable
(3) ignore

All can be written in terms of each other,
except for the performance issues:

foo_with_exception_error_handling() {
        if( foo_with_return_error_handling() ) {
                throw "foo error"
        }
}

bool
foo_with_return_error_handling() {
        try{ 
                foo_with_exception_error_handling();
                return false;
        }
        catch(...) {
                return true;
        }
}

foo_ignoring_errors() {
        .. is trivial ..
}

It is easier to implement foo_with_return_error_handling
in terms of foo_with_exception_error_handling 
than vice versa.
I have a standard macro in my library to do so

#define TRY(type,call)  {type ret; try { ret = call; } catch(...) {}; ret}

the above uses GCC/G++'s statement expressions.

Implementing foo_with_exception_error_handling()
in terms of foo_with_return_error_handling requires
more idiosyncratic knowledge - what's the error code?

---
Surely it should be possble to create a library that has
both flavours, in a generic manner?