From: John Maddock (jz.maddock_at_[hidden])
Date: 2008-05-30 14:50:43
Bruno Lalande wrote:
> Hi John,
> First of all: I'd like to ensure you had my response of may 27, since
> the mail system sent me today a notification saying it couldn't be
> delivered...?? When I search on Gmane I can see it so I think it's OK
> So finally, I think the best way is to create a new error. There are 2
> options: either we call it zero_power_error and it's bound to be only
> used in pow, or we call it undetermined_result_error so that it can be
> eventually reused later for something else. The default policy for
> this error will be ignore_error. If we choose "zero_power_error", the
> result in case of ignore_error will be 1. If we choose
> "undetermined_result_error", the best way is to make the result depend
> on the function where it's used. In this case, the
> raise_undetermined_result_error will have to take that value in
> parameter. For example, in pow:
> return policies::raise_undetermined_result_error<T>(
> "The result of pow<0>(%1%) is undetermined",
> T(1), // value to return in case of ignore_error
> Which of the 2 options do you prefer?
Generally I prefer generic rather than specific solutions, so I guess I'd go
for the latter - but would it be better called "indeterminate_result_error"
> For the throw_on_error policy, do you see any existing exception (std
> or boost) that could fit or is it better to create a new one?
Not sure, the only obvious one is domain_error. Otherwise we're left to
deriving a new exception type: would this gain us anything - storing the
return value maybe?
> For the errno_on_error policy, how about setting errno to EDOM and
> returning a NaN?
Yep, that's sensible, although should we return the value passed to the
function: that would be consistent with C99: return 1 but optionally set
errno as well.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk