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/
