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

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

-- 
James Kanze                                mailto:kanze_at_[hidden]
Conseils en informatique orientée objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. [phone]