Re: Exception handling Organization: unknown
On Sep 30, 2:45 am, Zeljko Vrba <mordor.nos...@fly.srk.fer.hr> wrote:
On 2009-09-28, Goran <goran.pu...@gmail.com> wrote:
Erm... What? High-level code detects that there's no network, so it
tries to work with the cache. File is not there, so __then__ it asks
the user whether she would like to connect? Well, I have certainly not
see a browser that does that. Rather, it just doesn't show stuff
that's not there and says nothing (that is, error is ignored). IOW,
your example is contrived.
Off-topic, but: Internet Explorer. Though, it sometimes gets confused and
wants to connect while WMP happily plays a live stream :)
Whoops! Sorry, tongue went before mind.
1. exception is already an object, so it's easier to add stuff
(context) to it. Error-return requires an elaborate context scheme and
that's done manually, and ends up in "to each his own" (does not scale
well).
Apropos that, where/how is that object allocated?
I have to ask: do you think that matters? I can easily say: no, it
does not. But let's explore that, fire away.
We must be working on a different types of code then. For the most
part, if I can't get a file handle, I am screwed - there's no point in
continuing. E.g. I'm going to read some description file that's
normally installed with the system - it must be there. Or, I'd like a
temp/other file handle to write something in. If I don't get it, I
can't possibly continue etc. Although I could do an "if" at every such
point, I'd rather not. So I'd like an exception to be thrown.
But that's just the point and my greatest annoyance with Java API - most
expected situations (file not found, error while converting int to string,
etc.) have been converted to exceptions. Thus, a simple, readable, short
idiom like
if(!(f = fopen(...))) ...
suddenly becomes
try {
f = WhateverJavaAPI(...);
} catch(IOException e) {
...
}
I have to repeat what I said before: you seem to be misunderstanding
most basic reason d'?tre for excaptions. (Also: let's not discuss
Java's __checked__ exceptions ;-)). Your code is is much more likely
to be:
try
{
f = WhateverJavaAPI(...);
work with f (several operations, all of whom might fail)
}
catch(const file_error& e)
{
crap!
}
Compare to error-return:
if(!(f = fopen(...))) crap!
if (!read(f...)) crap!
if (!read(f...))crap!
IOW, exception indeed do not work well if all you have is one single
operation that you want to check. I claim, that is seldom the case.
(As I said, just go and look at any error-return code base).
For a given code block, you know that program in fact tried to e.g.
read a configuration file. So you can report error like so: couldn't
read configuration, encountered system error X on file Y, e.g.
class config_error : public file_error {...};
(I assume that file_error already has file name and OS error code)
So even for one simple code block, you simplify the code: from a
handful of if statements, to one try/catch. And even that is seldom
necessary, as try/catch will more often than not span several levels
of stack (bar Java code ;-)).
But I guess I'm one of the few programmers who always check return codes. (I
have wrapped all OS calls into a THROW_IF macro that prints out an error
message and aborts in case the syscall fails.)
With your example -- where would you put the catch? How do you know in
general which exceptions to expect and where to catch them? [esp. when using
3rd-party libraries]
I am not sure what example you're thinking of, but I'll take a shot at
questions. One should put a catch at the __outermost__ place where
error __has__ to be handled. There's two reasons:
1. at a given place, if error, code should take a different path (any
cleanup operation does not count; perhaps we should discuss that)
2. we don't want to lose "context" so we want to augment original
error; e.g. in the snippet above, one could have:
catch(const file_error& e)
{
throw config_error(e);
}
Exceptions are so intrusive mechanism that no code should use it for reporting
anything but "something has become FUBAR." File not found, failing to parse an
integer, key not found in a dictionary are not FUBARs. Accessing a
non-existant element in a vector is (undefined behavior), as would be e.g.,
deleting an already deleted object (a situation sadly often not detected), or
corrupting a state of some object through a rogue pointer (and the object's
methods detect it).
Whoa, whoa... No, no, no, the last three are a cold crash. Exceptions
do not matter __in the slightest__. Just stop that.
When code loses control of it's memory, it's probably best that it
dies as quickly as possible. All of these problems are caused by a
prior __bug__; trying to continue __in any way__, exception
notwithstanding, might even further aggravate the situation.
Exceptions (like anything else, really) only work in bug-free code.
You are horribly, __horribly__ mistaken here!
Out of memory is a borderline case -- in the vast majority
of cases it is useful to declare it a FUBAR
To me, OOM is a clear-cut use case for exceptions. Having to check
every single allocation? No thanks, I've got better things to do in
life!
By the way, do you wrap all your non-trivial destructors in a try { }
catch(...) { } clause?
Ah... That's rule 0 of exceptions you're ignoring here: destructors
must not throw. That's not specific to C++, and there's more general
rule behind that. The rule is: cleanup operations always "succeed" (or
else, code is a mess). We can discuss that, too.
You also said something on the lines of "low-level operations are used
to check for existence of a file". Meh. First, there's likely a system
function for that. Second, there's presumption that if function says
that file exist means all will be well when code actually tries to
open it (otherwise, why would it ask if it's there?). That's a
stretch: it can get deleted in between, user might not have desired
access rights, etc. IOW, assumption that if file exists, something
else, done later, will work, is in general false.
There are valid use-cases for checking existence of a file, for example: do NOT
attempt to do something (e.g., execute a scheduled update, reboot a system) if
a certain file exists. That file might record, f.ex., progress of an ongoing
backup and its contents is not relevant to the program in question -- only its
existence.
Fair enough, however... I said (but now, with precision) "__First__,
use stat or PathFileExists" ;-). In a way, what you propose is a silly
design: you want to know if a file exists; to do that, you __open__
it. WTF, isn't there a better way!?
Goran.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]