Re: on the matter of exceptions
On Mar 10, 7:47 pm, Andrew <marlow.and...@gmail.com> wrote:
On Mar 10, 12:40 am, Jonathan Mcdougall <jonathanmcdoug...@gmail.com>
wrote:
[...]
When such an error is detected, I am
of the opinion that the program needs to crash immediately.
For some programs this is definitely the right thing to do, but not
for others. It depends on the program. The program I have in mind is
performing a large risk analysis on a book with hundreds of complex
multi-legged deals. The price of each of these is VERY expensive to
compute and each is a relatively isolated computation. A job that
computes the risk for the whole book needs to skip deals that won't
price due to coding errors like the one you gave. Yes, I know it's a
coding error, but these things happen in very large systems.
One obvious solution is to check point, and to provide a means
of continuing from that check point. (Another obvious solution
is to use a good development process that ensures that the
probability of such errors is practically zero. Easier said
than done, however; I work in a similar environment, and I know
that the environment doesn't encourage such a process.)
Having said that, there are a few cases where not crashing is
valid. One, obviously, is if the data isn't important: in a
games program, it's probably better to go on---if you crash
later, it's not worse than crashing immediately, and if you
don't, the player just experiences a quirk in the action.
Another is plug-ins of all sorts: crashing brings down the
complete application, and not just your code, and the rest of
the application may not know that check-pointing was necessary.
(And trying to debug the core dump you get from JVM or Excel is
not a forgone conclusion.) But of course, if you take that
attitude, then you've also got to catch segment violations and
continue as well.
The point was not whether assert() is a good way to assert,
but rather whether asserting is the right choice in some
cases.
Yes.
However, there are two problems with throwing a MyLogicError:
1) The calling code cannot do anything with it. If the query was badly
written, you'd need self-modifying code to fix it.
I disagree. My program *can* do something with it. In my
example the risk analysis skips that deal and goes on to the
next one.
Except that there is a non-negligible risk that memory for the
other deals has been corrupted as well. In ways that will give
wrong results. (I'm speaking from experience here, Luckily,
the results were so wrong that they were recognized as such.)
2) You have two *very* different paths while debugging and in
production.
Not with my approach you don't. I would throw a std::logic_error in
both cases.
Which may cause important information to be lost if you core
dump because of an uncaught exception.
I cordially dislike conditional compilation
So do I.
But again, I'm not sure we agree on logic errors. If I pass a nullptr to
a library that doesn't expect it, I want it to crash right there and
right now so I can know what happens.
I don't. I want my program to skip to the next deal (and reporting the
deal failure as a logic error of course).
I think the point is that there are cases (like mine) where you want
to be able to trap and handle the error and there are cases where you
want the program to blow up with a core dump. I am coming to the
conclusion that the behaviour needs to be configurable. IMO the place
to define this configuration in that part of the code that owns
"main". Libraries that may be used by both kinds of program need to
provide this configuration ability and invoke it from "main". Then we
will *both* be happy. The trouble is, there is no general purpose way
to do this so each library will do it differently. This is why, in the
meantime, I prefer the throwing approach. Programs like yours that
don't attempt to catch and handle logic errors will still just blow up
because the exception will bubble up to main.
In theory, VS offers such a choice at compile time: you choose
to use structured exceptions, or you don't. (In practice, I'm
not sure what happens to exception safety if a structured
exception occurs in a nothrow function.)
--
James Kanze
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]