[boost] Re: Function return utility class (originally Re: [boost]ReviewRequest: Filesystem Library)

From: David Brownstein (David_at_[hidden])
Date: 2002-08-01 13:58:10

Thanks for your response, I find your perspective to be very interesting.

> IMHO, this is completely the wrong direction. It always bothers me if
return values
> are misused as error codes. When a function returns a value, it should be
the result
> of a calculation, that is what functions do.
I disagree- many functions perform operations. For example, I hardly think
that the sockets function select() could be thought of as a "calculation".
Is writing a file a "calculation"?

> Your firts argument might be true, some people do care about performance.
I do not,
I was thinking especially about cases where functions (often OS API
functions) are frequently expected to return an "error" condition, and in
common usage are called repeatedly from a loop. An example would be a loop
that calls select() on a socket, specifying a timeout value so the call
doesn't block, and then if there isn't anything in the socket buffer to
read, continues doing some processing before coming back to the select()
call again. A similar scenario is (often?) used WRT non-blocking waitXXX()
calls on an event handle to see if an event has been signaled. In both cases
there are (often better) asynchronous methods of performing the same
operations, but that's not the point. The point is that it is both valid and
common for funcions to return error values, and 1) using exceptions here
would be somewhat clumsy to implement, and 2) very onerous from a
performance stand-point, where the exception might be thrown thousands of
times per second inside the loop!
I think in such cases the difference between "normal" (or "valid" from your
perspective) and "error" is questionable. Anyway I would argue that
returning an error code IS a valid use of a function return. It also has a
long history of such use in the standard C and C++ libraries, among others.

> When a function can't fullfill its
> postcondition, it has to report that as an error. If you want to return a
special
> errorcode, you have to widen the postcondition, which makes it harder for
> programmers to use the function. This is much more readable/usable:
>     Postcondition: !exists( ph )
> Compared to this:
>     Postcondition: !exists( ph ) || return_value != 0
> And you aren't ready there, because you should add things like
>     Postcondition: !exists( ph ) || (return_value != 0 && (return_value
== -1 when
> file not found) && (return_value == -2 when some other error) etc.
I agree with you. Error handling is messy, whether you handle it with a
return value or by throwing an exception. Either way you have to write the
similar code to handle the problem. I'm simply trying to combine the best of
both techniques.

> I don't think that your second argument holds.
I agree that it is weak. It was poorly expressed. What I was thinking of is
that sometimes a processing error doesn't matter, and can simply be ignored.
If the error is "signaled" by returning an error code, then the caller can
choose to ignore the return value. This is harder to do when the error is
signaled via an exception!

Thanks,
David