[Top][All Lists]

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

Re: [lmi] [PATCH] Add undisplayable_exception

From: Vadim Zeitlin
Subject: Re: [lmi] [PATCH] Add undisplayable_exception
Date: Thu, 9 Oct 2014 22:02:05 +0200

On Thu, 09 Oct 2014 19:00:28 +0000 Greg Chicares <address@hidden> wrote:

GC> Just one small question. Is there a reason why this extraordinary
GC> exception class should derive from std::runtime_error rather than
GC> from std::exception?

 This seemed like the most logical thing to do and seemed to be in line
with the use of std::runtime_error in other places in LMI code.

GC> Couldn't the GUI-test code sometimes throw something more like the
GC> standard logic_error classes:
GC>   {domain_error, invalid_argument, length_error, out_of_range}
GC> which [19.1.1/1] "report errors presumably detectable before the
GC> program executes, such as violations of logical preconditions or
GC> class invariants"?

 It could be argued that test errors are really none of those. E.g., to
take an example of a failure I just got when retesting the latest patch,
the "default_input" was failing because the default input file contained
2014-09-01 date instead of 2014-10-01, which was expected by the test as
we're already in October. Of course, this is not the only possible reason
for the test failure, but the sole fact that the test might fail because of
the external environment issues seems to me that the exception indicating
it ought to derive from std::runtime_error.

 However I freely admit that the standard C++ exception classes hierarchy
never made much sense to me anyhow, so I wouldn't be surprised at all if my
interpretation were wrong, and if you prefer to derive wx_test_exception
directly from std::exception -- or perhaps even not derive it from any base
class at all, as I think I'd prefer to do just to emphasize how special it
is -- we can do it like this, of course, just please let me know.


reply via email to

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