Re: [boost] Plea for addition of stream_cast

From: Ed Brey (brey_at_[hidden])
Date: 2000-06-06 09:56:32

From: "Mark Rodgers" <mark.rodgers_at_[hidden]>
> > What's benefit do you see in avoiding exceptions?
>
> I don't think exceptions should be used as a normal control
> mechanism; they should be reserved for exceptional circumstances.
> AFAIK, the costs of throwing an exception are quite high, and
> are not something we want to have to pay for regularly.

Agreed.  This leads to the question: What are the use cases in which
stream_cast fails in the course of normal operation?  Do they tend to
be such that the program needs stringstream's fail bit to make control
decisions?  Or are they such that a default or prespecified response
is acceptable?

Probably, most cases want to use the fail bit, either to have an
exception throw (so use stream_cast) or to use it directly (so use
stringstream).  I would suspect that there are few use cases where
returning a default initialized value is really the right thing to do.
However, there probably are a more significant number of use cases
where the client code wants to specify the default.  In this case,
stringstream is about equal to stream_cast in code appearance:

double d = 123.0;  // default
std::stringstream(foo) >> d;

This seems to be further reason to keep the stream_cast interface as
minimal and simple as possible.

> > Returning default values on failure is ambiguous, unless you
> > know from your context that the default would be impossible.
>
> Agreed.  But sometimes we may indeed know this:
>
>       int n = stream_cast<int>(argv[1], 0);
>       if (n < 5)
>       {
>           std::cerr << "x must be a number greater than 4.";
>           return EXIT_FAILURE;
>       }
>
> Do we care whether the user typed "fred" or "3"?  Possibly not.

This type of error handling scenario is a poster child for exceptions.
The exception overhead is insignificant, and it makes easy generic and
more robust error handling.  True, you don't need to tell to the user
that the parameter wasn't even a number, but sometimes it can be nice.
With exceptions, you can use the same code, or at least the same
coding pattern, for problems that do and do not have the luxury of
knowing that 0 (or whatever) is illegal and for problems that do and
do not need verbose error reporting.