[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