"J. M. De Moor" <✉nospamobjectpac.com> wrote in message
news:3b7872c3$1_1@dnews...

> Greg
>
> >
> >     if not fileExists(edit1.text) then raise exception.create('No such
> path
> > or filename');
> >     modalresult:=mrOk;
> > end;
> >
>
> Why would you need to raise an exception here?  Why not just open a dialog?

That's what happens anyway.


Let's say that the existence of a path isn;t the only validation that needs
doing. I can either write this :


if not validation then begin
    showmessage('blah blah');
    EXIT;
end;
if not validation2 then begin
    showmessage('blah blah');
    EXIT;
end;
if strToIntDef(etc)=-1 then begin
    showmessage('blah blah');
    EXIT;
end;
modalresult:=mrOk;


or this :


if not validation then
    raise exception.create('blah blah');
if not validation2 then
    raise exception.create('blah blah');
FSomeValue:=strToInt(edit1.text);
modalresult:=mrOk;


Both will show an error message and let the user correct the problem (which
is the only thing, in most cases, that the coder should be doing). The
latter is the more elegant.

> Isn't the usual way to handle exceptions with try-except blocks?  The idea

Only for certain circumstances such as batch processing and database
transaction support. If you follow the borland model of exception usage then
try..except should be outnumbered by try..finally's by 10 to1. In a project
I am working on at the moment I have 1 try..except and 7 try.finally's, and
I raise 7 exceptions. If you follow the model that appears to be suggested
in the OPLG then apparently our code should be littered by try..excepts. But
despite the manual that is not the model that Borland follow.

> is that you can interrupt the program's normal flow of control by catching
> exceptions and performing special handling in those cases, and moving back
> to an earlier point in the routine or call stack.  If you are checking a

You seem to be suggesting resumable exceptions which Delphi doesn't support.


In anycase I reckon the above is only true where a library is raising
exceptions when it should be returning false instead. And that's often the
case with components written by people who haven't understood exceptions.

> need for the raise.  Seems like a waste of resources.

It provides more elegant code and fits the criteria for exceptions.


The criteria being that for which the code cannot/should-not provide a
branch in the logic.


Greg