[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.
Thanks,
VZ
- [lmi] [PATCH] Add undisplayable_exception, Vadim Zeitlin, 2014/10/06
- Re: [lmi] [PATCH] Add undisplayable_exception, Greg Chicares, 2014/10/08
- Re: [lmi] [PATCH] Add undisplayable_exception, Vadim Zeitlin, 2014/10/08
- Re: [lmi] [PATCH] Add undisplayable_exception, Greg Chicares, 2014/10/09
- Re: [lmi] [PATCH] Add undisplayable_exception, Vadim Zeitlin, 2014/10/09
- Re: [lmi] [PATCH] Add undisplayable_exception, Greg Chicares, 2014/10/09
- Re: [lmi] [PATCH] Add undisplayable_exception, Vadim Zeitlin, 2014/10/09
- Re: [lmi] [PATCH] Add undisplayable_exception, Greg Chicares, 2014/10/09
- Re: [lmi] [PATCH] Add undisplayable_exception, Greg Chicares, 2014/10/09
- Re: [lmi] [PATCH] Add undisplayable_exception,
Vadim Zeitlin <=
- Re: [lmi] [PATCH] Add undisplayable_exception, Greg Chicares, 2014/10/11
- Re: [lmi] [PATCH] Add undisplayable_exception, Greg Chicares, 2014/10/11
- Re: [lmi] [PATCH] Add undisplayable_exception, Vadim Zeitlin, 2014/10/11
- Re: [lmi] [PATCH] Add undisplayable_exception, Greg Chicares, 2014/10/11
- Re: [lmi] [PATCH] Add undisplayable_exception, Greg Chicares, 2014/10/11
- Message not available
- Message not available
- Message not available
- [lmi] 31-character file-name limit, Greg Chicares, 2014/10/14
- Re: [lmi] 31-character file-name limit, Vadim Zeitlin, 2014/10/14
- Re: [lmi] 31-character file-name limit, Greg Chicares, 2014/10/14
- Re: [lmi] [PATCH] Add undisplayable_exception, Greg Chicares, 2014/10/10
- Re: [lmi] [PATCH] Add undisplayable_exception, Vadim Zeitlin, 2014/10/11