Prev: A member of type vector<self>
Next: Can I store lambdas for the future?
From: Daniel T. on 8 Mar 2010 12:23
Seungbeom Kim <musiphil(a)bawi.org> wrote:
> Daniel T. wrote:
>
> > 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.
>
> How do you fix the program so that opening a nonexistent file doesn't
> occur? How do you know that the file is nonexistent and cannot be opened
> until you really try to open it?

I expect you thought about your question after posting, and you figured
out the answer... If not...

Let's say your program needs to display some bmp image for a button (I
do this all the time in games and educational software.) Let's also say
that the file is nonexistent. How do you fix that? The obvious answer is
to make the bmp file and put it where it belongs.

Let's say that there is some file that *must* exist at location Y in
order for your program to work properly. What should the code that
attempts to open the non-existant file do?
a) Should it simply abort the entire program with no information given
to the user as to why and without attempting to save any user generated
content?
b) Should the function crash the program because assertions were
compiled out of the release version?
c) Should the function throw an exception so that the program can exit
cleanly with a message telling the user to re-instal or whatever?

To me, answer (c) is correct, but maybe you can think of a better answer?

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Seungbeom Kim on 9 Mar 2010 09:47
Daniel T. wrote:
> Seungbeom Kim <musiphil(a)bawi.org> wrote:
>> Daniel T. wrote:
>>
>>> 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.
>> How do you fix the program so that opening a nonexistent file doesn't
>> occur? How do you know that the file is nonexistent and cannot be opened
>> until you really try to open it?
>
> I expect you thought about your question after posting, and you figured
> out the answer... If not...

You are implying it was so silly a question that I could figure out
the answer myself later, but I was asking because I couldn't and
something was not clear about your argument.

>
> Let's say your program needs to display some bmp image for a button (I
> do this all the time in games and educational software.) Let's also say
> that the file is nonexistent. How do you fix that? The obvious answer is
> to make the bmp file and put it where it belongs.

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.
Of course it would be silly not to make and provide the file needed,
but you cannot guarantee that it will always stay intact: the user could
delete the file by mistake, or the file could have been installed in a
remotely mounted directory and the directory could be unmounted when
the program ran.

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.

>
> Let's say that there is some file that *must* exist at location Y in
> order for your program to work properly. What should the code that
> attempts to open the non-existant file do?
> a) Should it simply abort the entire program with no information given
> to the user as to why and without attempting to save any user generated
> content?
> b) Should the function crash the program because assertions were
> compiled out of the release version?
> c) Should the function throw an exception so that the program can exit
> cleanly with a message telling the user to re-instal or whatever?
>
> To me, answer (c) is correct, but maybe you can think of a better answer?

Of course I choose (c). Did I say or imply otherwise?

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.

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.

--
Seungbeom Kim

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 | 
Pages: 1
Prev: A member of type vector<self>
Next: Can I store lambdas for the future?