lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Use of range_error standard derivatives


From: Vadim Zeitlin
Subject: Re: [lmi] Use of range_error standard derivatives
Date: Mon, 20 Mar 2017 00:41:52 +0100

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? From practical point of view,
I don't remember ever writing any code catching any of these classes
specifically rather than runtime_error (or, often enough, just
std::exception itself) and the only place where I see it in lmi code (in
Server7702::Process() function) doesn't really see to do anything useful
with it: it does set "implausible_input" bit, but it doesn't seem to be
tested later, AFAICS.

 Under duress I could admit that overflow_error might be conceivably
useful, but the other two just don't seem so and, moreover, their
suitability in the present case is not immediately obvious, so I would
avoid the problem entirely and just not use neither of them at all.

GC> Vadim, what would you say to a proposal to change those to:
GC>         throw std::range_error("Cast would convert negative to unsigned.");
GC>         throw std::underflow_error("Cast would transgress lower limit.");
GC>         throw std::overflow_error("Cast would transgress upper limit.");
GC> ?

 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.

 Regards,
VZ


reply via email to

[Prev in Thread] Current Thread [Next in Thread]