Myles is right. Local variables with a few exceptions are not initialised. It is a real trap to code assuming things are initialised. One example is the "Result" implicit variable. It is NEVER initialised regardless of type, and if you try to refer to it, especially if the result type is string, you will get very hard to track bugs. Another trap for the string return type is if you forget to assign a value to Result and exit the function. The caller will get back essentially junk result! And the compiler does not even produce a warning!
Assuming variables are initialised is generally a very poor coding practise and should be avoided at all costs. it is safer and clearer to always explicitly initialise all variables before using. > (in line with this discussion, a possible memory leak if an exception is > raised on the interface release/variant clear) That is why in server code you should explicitly set interface references to Nil and protected inside a try--except block. Variants should be explicitly set to Null or Empty and also adequately protected. Strings and arrays should be explicitly set to blank, etc. Doing this may seem over cautious, but it is the difference between a poor server app and an acceptable one. ----- Original Message ----- From: "Myles Penlington" <[EMAIL PROTECTED]> To: "'NZ Borland Developers Group - Delphi List'" <[EMAIL PROTECTED]> Sent: Friday, March 05, 2004 9:36 AM 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
