Article

From:
To:
J. M. De Moor
Subject:
Re: Exceptions vs Error codes
Newsgroup:
borland.public.delphi.objectpascal

Re: Exceptions vs Error codes



"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.
> condition explicitly and the flow continues from there, then I don't see the
> 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
FYI: Phrase searches are enclosed in either single or double quotes
 
 
Originally created by
Tamarack Associates
Wed, 09 Oct 2024 16:43:43 UTC
Copyright © 2009-2024
HREF Tools Corp.