Re: [lmi] Use of range_error standard derivatives

[Greg Chicares]

On 2017-03-19 23:41, Vadim Zeitlin wrote:
> On Sun, 19 Mar 2017 16:14:36 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> The standard gives virtually no guidance for the use of these classes:
> GC>   range_error: "range errors in internal computations"
> GC>   overflow_error: "arithmetic overflow error"
> GC>   underflow_error: "arithmetic underflow error"
> GC> The only apparent reference to any of them in TC++PL4 actually refers
> GC> to ERANGE. I tend to conclude that any reasonable use is good.
> GC> 
> GC> The reason why I raise this matter now is to ask which exceptions
> GC> bourn_cast should throw. Right now, it looks like this:
> GC> 
> GC>     if(! to_traits::is_signed && from < 0)
> GC>         throw std::runtime_error("Cast would convert negative to 
> unsigned.");
> GC>     if(from_traits::is_signed && from < to_traits::lowest())
> GC>         throw std::runtime_error("Cast would transgress lower limit.");
> GC>     if(to_traits::max() < from)
> GC>         throw std::runtime_error("Cast would transgress upper limit.");
> GC>     return static_cast<To>(from);
> GC> 
> GC> Clearly they're all runtime_errors, but should we be more specific?
> 
>  I might be just exposing my own ignorance here, but I don't see why would
> they need to be more specific. From the theoretical point of view, it's
> important to distinguish between different kinds of errors in C API such as
> errno() by returning ERANGE etc because there is no other way to
> distinguish between them, but here we already have an error message
> explaining it, so why duplicate its meaning?

Thanks. This:
  throw std::overflow_error("Overflow detected.");
really doesn't make a lot of sense.

The existence of these fine-grained exception types creates a temptation
to use them, but there are some things in the standard that have turned
out not to be very useful.

>  All this being said, I don't see any real problem with doing this neither.
> I would, however, be curious to see where do you think catching these more
> specific exceptions, rather than runtime_error, would be useful.

That's pretty much an unanswerable argument against using these derived
exception classes, in this case at least. I hadn't seen others use them;
now I understand why.