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

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-03-21 08:50:50

From: Glew, Andy [mailto:andy.glew_at_[hidden]]
> 
> These are the following basic error handling techniques:
> (1) exceptions
> 	- errors are rare, and should not be ignored

I would counter that exceptions are appropriate when errors must not be
ignored, rare or not.

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

You can't write (1) or (2) in terms of (3), but otherwise I agree with you.

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

>From what I can see, ret is not assigned a value if "call" throws an
exception.  Furthermore, TRY() catches and ignores *all* exceptions.  That's
rarely a good idea.

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

You're assuming that any exception maps to a single return value.  If you
must decode the exception(s) to get different return values, then it doesn't
matter whether (1) is written in terms of (2) or vice versa; the outer
function must know exactly which errors the inner function reports and how
to translate them.  To effect (1) in terms of (2), you simply need a switch
or cascading if's to determine the exception to throw for each error return
value.

Granted, if the exception type you throw contains an error code -- which
std::exception does not allow for -- then you could extract and return that
code, thus making (2) in terms of (1) almost like your TRY() macro.

Despite all of the above, my contention is simply that remove() should
return a value to indicate whether the relatively benign "error" of the file
to remove not existing.  I'm not advocating that it be written in either or
both forms (1) and (2).

Rob
Susquehanna International Group, LLP
http://www.sig.com