Yeah, 30 seconds worth of testing my memory would have proved me a chump, and I wouldn't have embarassed myself. I've never done it like that before, I just put two and two together and it came up five.
-----Original Message----- From: David Brennan [mailto:[EMAIL PROTECTED] Sent: Friday, March 05 2004 9:46 a.m. To: NZ Borland Developers Group - Delphi List Subject: RE: [DUG] try..finally : Which way is best? Mmmm. I thought we had pretty much covered this yesterday. Under Delphi 5 at least (I am beginning to wonder if later versions are different from the number of people posting these sort of alternatives) your suggested solution will result in 3 warnings about changes, issues and terrorists possibly not being initialized. This is bad - you should never have warnings or hints in your application. You may technically be correct - it seems Delphi does generally initialise object references to nil but my understanding is that this is an undocumented feature. Officially Delphi does NOT initialise local variable object references and the compiler gives warnings occordingly. So, I still stand by my statement that the solution raised by Paul Needham is the shortest safe way of handling errors in the create (as Dennis points out more work is required to safely handle potential destroy errors). David. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Allan, Samuel > Sent: Friday, 5 March 2004 9:32 AM > 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
