Re: Exception handling Organization: unknown
On 2009-09-28, Goran <goran.pusic@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 :)
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?
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) {
...
}
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]
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). Out of memory is a borderline case -- in the vast majority
of cases it is useful to declare it a FUBAR.
There's nothing preventing you from defining your own FUBARs in your
application, but general-purpose code (libraries) should not declare common
conditions (file not found) as such.
By the way, do you wrap all your non-trivial destructors in a try { }
catch(...) { } clause?
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.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]