"Kristofer Skaug" <✉skaug.demon.nl> wrote in message
news:3b784177_2@dnews...

>
> "Greg Lorriman" <✉bigfoot.com> wrote in message
> news:3b781c99_2@dnews...
> > Absolutely not! I am saying that it is unreasonable for MS Word to do
> > anything other than abort if the user provides a false path in the open
> > dialog. What is the programmer supposed to do? Is he supposed to attempt
> to
> > find a file whose soundex is similar? That would be unreasonable. There is
> > no reasonable contigency and it's obvious that user intervention is
> needed.
> > This situation is asking for an exception.
>
> ? it is? if your program just detects that no such file (as specified) is
> present or valid, all it needs to do is display an error message and offer

like this :


    if not fileExists(edit1.text) then raise exception.create('No such path
or filename');
    modalresult:=mrOk;
end;


By "abort" I didn;t mean make the dialog box disappear and therefore force
the user to start again.


As you can see the above fulfills your requirements (assuming that the OK
button has had it;s modalResult property changed to mrNone). It's also a
pattern for dialog box validation in general ( you could have a lot more
statements before that modalResult:=mrOk)..

> this as part of the anticipated behaviour of a function (and the user
> input), not as an exceptional case (SNAFU, idiot users, etc.).

I don;t think that I said that exceptions are for unanticipated situations.
Obviously exceptions cover the unanticipated, but often the unanticipated
turns out to be a bug. My emphasis is on contracts being broken or, if you
like, invalid parameters. A bad path is an invalid paramter to the "open"
method. The code needs a valid path and that is the contract to which the
user signs up.


There are going to be situations where a bad path is actually part of the
proper functioning of the program (none come immediately to mind). In which
case I wouldn;t use an exception, rather a branch in my logic.


Greg