Re: I keep running into long term c++ programmers who refuse to use exception
daniel_t@earthlink.net (Daniel T.) wrote (abridged):
So we have two different scenarios on the table:
A) The program tries to open a file that is necessary for correct
function. This file is provided with the program and put in the
correct place during program installation.
B) The program tries to open a file that would be useful but isn't
necessary for correct function. A file name is provided by the user.
[...]
For scenario B, don't use the OP's FileOpen function. In this case,
the program is not in error, the user is in error. Your program should
expect users to make errors like that, and their errors should not
cause your program to shutdown/reset.
Here's how I usually handle that situation. At the point in the UI that
the user provides the filename, we validate it, including a check that it
exists. At this point we don't want an exception. We're half-expecting
the user to get the name wrong.
Then the filename gets handed off to some other part of the program,
which eventually uses it. At this point we do want an exception if it
doesn't exist. It's an error, but not a programmer error and not an
irrecoverable error (we recover by returning to the UI, telling the user
what happened and asking for a new filename). It's not an expected error
(it can only happen if some other process interferes with the file
between the UI and the use, which will be extremely rare).
For me, a lot of exceptions are of this sort. They almost never represent
programmer errors. They are usually resource errors. Running out of
memory is a ubiquitous one. They are not irrecoverable and should not
cause the program to shut down, but usually mean whatever the user just
tried to do can't be done.
-- Dave Harris, Nottingham, UK.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]