My guess is that you may have read about object data being initialised and just misread it.
It would certainly be nice if Delphi did initialise local variables for you where necessary. I suspect it initially wasn't done for performance reasons (ie no point in initialising it if the user is just going to set it anyway) but these days they should be able to write the compiler so that it only initialises the local variables if it has to (ie if the code doesn't explicitely initialise it). Of course this may just mean coders make more mistakes as they would no longer get warnings about local variables which they had meant to explicitely initialise and simply forgot... Tough call. David. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Allan, Samuel > Sent: Friday, 5 March 2004 10:34 AM > To: NZ Borland Developers Group - Delphi List > Subject: RE: [DUG] try..finally : Which way is best? > > > I do apologise. You are quite right. I was sure I read that object > references were also initialised to nil somewhere in the help, but that > was months ago, so I guess I didn't. > > -----Original Message----- > From: Myles Penlington [mailto:[EMAIL PROTECTED] > Sent: Friday, March 05 2004 9:37 a.m. > To: 'NZ Borland Developers Group - Delphi List' > Subject: RE: [DUG] try..finally : Which way is best? > > > Not quite right. > > Local method variables are not initiliased - except for strings, > variants > and interface references. When an object is created, the object data is > initialised to binary zero, which nicely equates to empty strings, > interfaces etc. > > Also if you declare any local strings, variants or interface references, > your method has an automatic try finally block added by the compiler - > note > (in line with this discussion, a possible memory leak if an exception is > raised on the interface release/variant clear) there is only 1 try > finally > block added for all the variables that have to be finalized on exit from > the > method. > > Myles. > > -----Original Message----- > From: Allan, Samuel [mailto:[EMAIL PROTECTED] > Sent: Friday, 5 March 2004 09:32 > To: [EMAIL PROTECTED]; NZ Borland Developers Group - Delphi List > Subject: RE: [DUG] try..finally : Which way is best? > > > And all object references are set to nil automatically by the compiler, > so you can skip the bob := nil stuff at the start. Unless you were using > the same variable for two different purposes... That being the case, I > would go with (as previously suggested): > > try > changes := TChangesList.Create; > issues := TIssuesList.create; > terrorists := THardToFind.create; > > ... > > finally > terrorists.free; > issues.free; > changes.free; > end; > > If any of the constructors fail, that object gets cleaned up > automatically. It's reference is never set to not nil. All objects are > either freed or not correctly, depending on if the reference was ever > set to not nil (it was created successfully). > > > -----Original Message----- > From: Nahum.Wild [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 04 2004 4:31 p.m. > To: 'NZ Borland Developers Group - Delphi List' > Subject: RE: [DUG] try..finally : Which way is best? > > > Cool my new thing learn't for today! I didn't acutally know you could > safely call free on a nil'ed class/pointer. I've been assuming since D1 > that you couldn't. That has just changed my outlook a bit. > > Thanks. > > Nahum. > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of Paul Needham > > Sent: Thursday, 4 March 2004 16:17 p.m. > > To: 'NZ Borland Developers Group - Delphi List' > > Subject: RE: [DUG] try..finally : Which way is best? > > > > > > Not so. Check the help on free. > > It is perfectly safe as long as issues and terrorists were set to nil > > first. I think the compiler shows warnings if you don't > > anyway. I could > > have also explicitly checked to see if they were assigned in > > the finally > > but don't generally bother as this is what free does anyway. I am > > willing to concede that calling destroy would be bad though 8). > > > > Paul > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > > On Behalf Of Nahum.Wild > > Sent: Thursday, 4 March 2004 4:08 p.m. > > To: 'NZ Borland Developers Group - Delphi List' > > Subject: RE: [DUG] try..finally : Which way is best? > > > > If issues fails then the finally will try to free terrorists, > > which will > > probably cause another exception. :o) > > > > Nahum. > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] Behalf Of Paul Needham > > > Sent: Thursday, 4 March 2004 15:59 p.m. > > > To: 'NZ Borland Developers Group - Delphi List' > > > Subject: RE: [DUG] try..finally : Which way is best? > > > > > > > > > How about..... > > > > > > issues := nil; > > > terrorists := nil; > > > changes := TStringList.create; > > > try > > > issues := TIssuesList.create; > > > terrorists := THardToFind.create; > > > > > > ... > > > > > > finally > > > terrorists.free; > > > issues.free; > > > changes.free; > > > end; > > > > > > Paul > > > DBSolutions > > > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] > > > On Behalf Of Nahum.Wild > > > 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 > > > > _______________________________________________ > 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 > _______________________________________________ Delphi mailing list [EMAIL PROTECTED] http://ns3.123.co.nz/mailman/listinfo/delphi
