I looked at the more general case than just a DB application. It still
depends on how often the code is executed, or what the important path is. To
me if you wrapped the code with a try except block, I would by default treat
this as a "I never expect this condition to occur in normal operations".
Just to really get into the swing of friday afternoon ...
On another course this ("Datasource.DataSet.Connection") is regarded by many
- based on my understanding (of reading quite a few but still not enough
books on OO design etc) as bad OO coding as it leads to high coupling
between classes.
The more accepted( better ?) way of doing this would be
"Datasource.Connection" and then adding the correct method/property to the
datasource object. Go figure!
Of course the Horses for courses rules always apply... and how big is your
app and how long will it be alive ...
Myles.
-----Original Message-----
From: Paul Ritchie [mailto:[EMAIL PROTECTED]]
Sent: Friday, 2 November 2001 3:36 p.m.
To: Multiple recipients of list delphi
Subject: RE: [DUG]: Best practice - To except or not
At the risk of not appearing to not enter into the spirit of the discussion
;) aren't you talking about a database application?
Therefore the number of clock cycles you can save by coding a certain way
over another is more than swamped by relatively slow database operations.
Therefore I'd err on the side of selecting what is easiest to maintain in
the future.
Paul.
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Myles Penlington
> Sent: Friday, 2 November 2001 3:18 p.m.
> To: Multiple recipients of list delphi
> Subject: RE: [DUG]: Best practice - To except or not
>
>
> Take your pick. Paul is quite right in this statement.
>
> The overhead in setting up and taking down exception frames
> is reasonably
> light (something equivalent to about 4 assignments), however
> the overhead in
> raising an exception (and the OS raising an AV) is huge by comparison.
>
> Depends on the numbers of how often you expect it to fail. If
> never then I
> would tend to use the exception handler.
>
> Myles.
>
>
> Neven asked:
>
> > If you are following a trail of properties, ie
> > Datasource.DataSet.Connection
> > is it be to test for assignment/nil a each step or
> > just try except it?
> >
> > ie
> > if (Datasource <> nil) and
> > (Datasource.DataSet <> nil) and
> > (Datasource.DataSet.Connection <> nil)
> > then Result := Datasource.DataSet.Connection
> > else Result := nil;
> > or
> >
> > try
> > Result := Datasource.DataSet.Connection
> > except
> > Result := nil
> > end;
>
> From an efficiency point of view, setting up and collapsing
> exception frame
> is not free.
>
> Whether it's cheaper than the code to test all the pointers
> against nil
> would depend on how many you were testing. I haven't examined
> the generated
> code but I would not be suprised if it took quite a few
> pointer tests before
> the exception handling overhead was a net win.
>
> Now, if the exception is actually _fired_, you'd be paying
> lots of cycles so
> I wouldn't use this idiom where you expect Result to be nil
> very often.
> Exception processing itself is not cheap - it should only
> really be used for
> catching rare cases (hence the name exception I suppose :-)
>
> The efficiency concerns would put me off using this idiom,
> but from a style
> point of view, I'd say it's a matter of personal preference.
>
> TTFN,
> Paul.
>
>
> --------------------------------------------------------------
> -------------
> New Zealand Delphi Users group - Delphi List -
> [EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
> To UnSub, send email to: [EMAIL PROTECTED]
> with body of "unsubscribe delphi"
> Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
> --------------------------------------------------------------
> -------------
> New Zealand Delphi Users group - Delphi List -
> [EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
> To UnSub, send email to: [EMAIL PROTECTED]
> with body of "unsubscribe delphi"
> Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
>
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"
Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"
Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
