Re: I keep running into long term c++ programmers who refuse to use exceptions
Seungbeom Kim <musiphil@bawi.org> wrote:
Daniel T. wrote:
What we're discussing here is what the program should do once it
ships, runs on the customer's computer and finds that it cannot open
the file.
That can't happen in my domain (console games.) A missing file means
that we screwed up. Same goes with a failed memory request.
Another scenario I was thinking of is that the filename is supplied by
the user. You can never guarantee the file can be opened successfully.
See below.
Your argument was: (repeated here)
For your example, the fact that your FileOpen function throws an
exception if the file doesn't exist means that it is an *error* to
call FileOpen and pass in the name of a nonexistent file. What this
means is that if FileOpen throws its exception during some run of
the program, you should *not* add a catch, instead you should fix
the code so the exception is no longer thrown.
It looks like I overstated my case with the last clause of the last
sentence. Sorry about that.
I am saying that no matter how well you write your program, some
run-time failures are inevitable, in which exceptions can be thrown,
and that you should be prepared to catch them. And that it can be
impossible to fix the code so that exceptions are no longer thrown,
and that it may not be an error in the code.
When designing a program, one of the cases we have to consider is what
to do if something goes wrong and a shutdown/reset is required. Whatever
procedure is decided on goes in catch block(s). In other words, you put
in catch blocks because you realize you need to do something special
before shutdown/reset when something goes wrong, you do *not* put them
in simply because a particular function might throw or because that
function threw during QA testing. In the simplest case, you don't need
to do anything before shutdown/reset and in that case there wouldn't be
any catches in the program at all, no matter how many throws might exist.
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 A, use the OP's FileOpen function and if it throws, your
regular error handling and shutdown/reset system will deal with it. As I
said before, you should *not* add a catch just because FileOpen might
throw.
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.
As I said before, a good indicator of a poorly planned/programmed system
is if there are a bunch of empty catch blocks lying around or if they
catch errors and "fix" them without re-throwing the exception (of course
the top level catch block need not re-throw.) Such code generally means
that the programmer was *expecting* the exception and using it for
normal program flow. Of course the real world is sometimes messy and
sometimes we don't have any choice, but such code is best avoided. A
thrown exception represents an unrecoverable error.
Hopefully this is more clear and less controversial.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]