Boost logo

Boost :

From: James Kanze (kanze_at_[hidden])
Date: 2002-04-08 01:00:38

"Glew, Andy" <andy.glew_at_[hidden]> writes:

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

There's also the global variable (errno), or internal state, à la
iostream. And callbacks (Cobol's ON ERROR clause).

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

Once you've ignored the error, you can't turn it into an exception or a
return code.

In general, I would argue for a return code for any error you might want
to ignore. Realistically, catching and ignoring an exception is a pain,
independantly of the performance issues. My experience would suggest
that it is easier (or more natural) to map a return code to an error
than vice versa.

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

My experience suggests the contrary.

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

And returns an undefined error code for built-in types if call throws.

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

Any conversion of the error code requires some knowledge of the error

James Kanze                                mailto:kanze_at_[hidden]
Conseils en informatique orientée objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

Boost list run by bdawes at, gregod at, cpdaniel at, john at