Re: Exception Misconceptions: Exceptions are for unrecoverable
errors.
In article <091743a1-e305-4cee-b65d-1fe82fc2b0f7@z41g2000yqz.googlegroups.com>, James Kanze <james.kanze@gmail.com> wrote:
On Dec 22, 3:15 pm, "dragan" <spambus...@prodigy.net> wrote:
Saying "Exceptions are for unrecoverable errors" seems to
imply that they are to be used only or mostly in such
situations.
Maybe, maybe not. It probably depends on what whoever is
saying it means by "unrecoverable". (But I've never heard
anyone say it, so I don't know the context.)
I like that one!
You do have a style and insight more than most people I saw.
That is why whenever I end up seing some articles while verifying
sites, and there is thread I am looking on, and there is article
from James Kanze, THAT is the article I am going to read first.
That is pretty much guaranteed.
To tell you the truth, I do not have even a concept of
"unrecoverable" error. Unrecoverable errors occur ONLY if my
box dies more or less.
In that case, exceptions or mental masturbation about them,
means as much as a dead mosquito fart. We are screwed.
But, as soon as I reboot, ALL I need to do "to recover",
is to push a SINGLE button. Since even the operation and ALL
its parameters will be automatically reloaded. Cause it is
all as persistant as it gets.
Not a big deal. I lost a couple of minutes of my time
and had a chance to go take a leak, instead of being glued
to the screen. What a pleasure!
:--}
Whereas the exception machinery in C++ was developed primarily
to handle and RECOVER from more errors more elegantly than was
possible without exceptions, the statement is highly suspect.
It depends on the error. At the lowest level, where a simple
retry suffices, exceptions complicate error handling.
I do not agree. Sorry.
You DO have this tendency...
:--}
Ok, how do you retry a network connection?
You sit in some dumb loop and keep doing the same stoopid
thing, and you might have to do several things during
the connection process depending on what kind of protocols
the sever supports, and whether you need to do authentication
and what kinds of authentication methods sever supports,
or whether sever returns tens of codes, some of which may
be temporary off-line conditions to be retried.
Some may be permanent errors.
Some may be resource issues, and you name it.
So, to me, I just give a dead flying chicken what kind of
error server might have. There is only 2 level granularity
of exceptions.
I do not check ANY return codes more or less.
I can be thrown on two levels only, at most 3.
And ALL that funky logic does not have to be there.
Yes, I understand that your program does need logic.
Otherwise it is just a dumb state machine, even though
the very logic is already wired in into that state machine.
After all, they do execute conditional jumps depending
on which input bit is active.
Those "unrecoverable errors" are probably the things that
assertion checking weeds out during development time rather
than being an application for exception machinery.
If that's what is meant by "unrecoverable", then exceptions are
certainly not for unrecoverable errors. In such cases, it's
important (in most applications---there are exceptions) to kill
the process as soon as possible, without any stack walkback.
"Unrecoverable error": throw up a dialog for the developer and
exit (or crash to keep the call stack in view in the
debugger).
Exactly. And that's not what exceptions do.
Exceptions, are more appropriately used where there is a
likelihood of recovering from the error condition rather than
being just for "unrecoverable errors".
Again, it depends on what you mean by "recovering". If you just
have to try again (e.g. user input error), then a simple while
loop is a lot simpler than an exception.
:--}
I like THAT one. Nice style!
Exceptions are useful
when you can't really do anything about the error locally.
Not necessarily.
Again the string to number conversion exceptions.
Can be handled as locally as it gets.
And plenty of other things.
I don't think there is such a rule for it.
Which often means that "recovery" is more or less impossible,
since once you've left "locally", you've lost all of the
necessary context to retry.
Not really.
You did loose the context withing the same stack frame.
Not a big deal.
Just make sure you handle that exception and clean up
some memory, even in Java you don't even have to worrry
even about doing that much.
Some local operation could be easily retried by the higher
levels in vast majority of situations, unless you read some
obviously wrong configuration parameter and it is not
going to work no matter how many times you retry it.
In that case, you throw on a higher level, after displaying
or logging the lower level, more precise and more detailed
result.
After that, you catch it on higher levels, and those levels
know much better what the whole operation is all about.
If they decide that, sorry, this can not be done even on
this level, they can rethrow even rougher generality
expception to the highest level loop.
At that point, your highest level logic knows what to do.
Either to wait for some time and try to retry, say in cases
where you lost a connection, which should be restored by
the O/S in a relatively short time.
Or, to simply abandon one of your major operations
and go on with the next item on the job list, if you have
anything like this, and THAT is where things become most
tricky.
But maybe you mean something different by "recovering"?
Futher discussion of the application of exceptions is
appreciated. Keep in mind that while there are SOME general
vague "principles" of the application of exceptions, mostly
the scenarios need to be defined for fruitful discussion.
Please keep the examples simple but realistic and note the
assumptions you make.
Concrete example:
//! \pre
//! No current output set up...
void
SomeClass::setupOutput()
{
assert(! myOutput.is_open());
Jesus!
std::string filename = getFilename(); // Dialog with user...
myOutput.open(filename.c_str());
while (! myOutput.is_open()) {
reportErrorToUser();
filename = getFilename();
myOutput.open(filename.c_str());
}
}
Use of exceptions here would only make the code more
complicated. (Try writing it in Java sometime:-). Where
failure to open a file is reported via an exception.)
--
Programmer's Goldmine collections:
http://preciseinfo.org
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.