So I could create a new rule for myself that went something alone the lines
of :

"if I'm sure it's not a problem then a single try..finally is ok, otherwise
nest them"

That works for me.

What would be really cool would be something like this :

--

procedure THardToFind.hideInCave(const cave : TCave);
var
  hiddenTraps : TTrapsList.create(cave);
begin

// explore cave and lay traps keeping hat on to protect head etc...

end;

--

So hiddenTraps is immediatly available and gets freeded at the end of the
method.  Interfaces can get you something close to this but not quite.
Maybe if I turned writeableconsts on it could work....



Nahum.

> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Myles Penlington
> Sent: Thursday, 4 March 2004 16:05 p.m.
> To: 'NZ Borland Developers Group - Delphi List'
> Subject: RE: [DUG] try..finally : Which way is best?
>
>
> I find creates are not usually an issue - unless it is
> TControl descendant.
>
> For me, more things go wrong on the free's than anywhere else.
>
> If the code is not speed critical, then use multiple try blocks.
>
> Myles.
>
> > -----Original Message-----
> > From: Nahum.Wild [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, 4 March 2004 3:37 p.m.
> > To: 'NZ Borland Developers Group - Delphi List'
> > Subject: [DUG] try..finally : Which way is best?
> >
> >
> > Ok so this is something that has bugged me for ages, partly
> > because I don't
> > know and partly because I can't be bother trying to figure it out.
> >
> > is the following code ok? or should I give each it's own
> try..finally?
> >
> > --
> >
> > changes := TStringList.create;
> > issues := TIssuesList.create;
> > terrorists := THardToFind.create;
> > try
> >
> > // stuff is done, planes flown.  That type of things.
> >
> > finally
> >   terrorists.free;
> >   issues.free;
> >   changes.free;
> > end;
> >
> > --
> >
> > I mean what could go wrong in the TStringList.create constructor for
> > example?  It's not like there should be anything much in
> > there that could go
> > wrong anyway?  Because if it does except the destructor will
> > be immediately
> > called - learnt that one the hard way many years ago.  As a
> > general rule of
> > thumb I don't put anything significant in a constructor for
> > my own classes -
> > that's what init or setup methods are for.
> >
> > For the record I've never done it this way, I've always given
> > each their own
> > try..finally.
> >
> > Thoughts anyone?
> >
> >
> >
> > Nahum Wild
> > Software Innovator & Process Consultant
> > IFE
> > PayGlobal
> >
> > _______________________________________________
> > Delphi mailing list
> > [EMAIL PROTECTED]
> > http://ns3.123.co.nz/mailman/listinfo/delphi
> >
> _______________________________________________
> Delphi mailing list
> [EMAIL PROTECTED]
> http://ns3.123.co.nz/mailman/listinfo/delphi
> _______________________________________________
> Delphi mailing list
> [EMAIL PROTECTED]
> http://ns3.123.co.nz/mailman/listinfo/delphi
>

_______________________________________________
Delphi mailing list
[EMAIL PROTECTED]
http://ns3.123.co.nz/mailman/listinfo/delphi

Reply via email to