tag:blogger.com,1999:blog-3782954984366933851.post4941532283557216752..comments2023-06-19T01:22:31.258+12:00Comments on Steve's Software Development Blog: Use of Try/Except/FinallySteve Peacockehttp://www.blogger.com/profile/03155137500284265720noreply@blogger.comBlogger12125tag:blogger.com,1999:blog-3782954984366933851.post-28310608962434189192007-08-31T20:11:00.000+12:002007-08-31T20:11:00.000+12:00Cheers steve, your second example clears it up for...Cheers steve, your second example clears it up for me, its added to my snippets" list (rapidly growing).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3782954984366933851.post-88728024297280554822007-08-31T08:18:00.000+12:002007-08-31T08:18:00.000+12:00Chris, I think I know what you are getting at now....Chris, I think I know what you are getting at now. You expect a single try for both except and finally.<BR/><BR/>this is where the Delphi sentance comes in. They are both seperate sentences and therefore treated as seperate. It is the underlying structure of Pascal that allows for the different statements of try/except and try/finally.<BR/><BR/>Good to see a returning programmer coming back into the world of delphi. I'm sure you will enjoy it.<BR/><BR/>SteveSteve Peacockehttps://www.blogger.com/profile/03155137500284265720noreply@blogger.comtag:blogger.com,1999:blog-3782954984366933851.post-28031792396063485272007-08-31T07:41:00.000+12:002007-08-31T07:41:00.000+12:00Chris,Of course you can. the try/except and try/fi...Chris,<BR/>Of course you can. the try/except and try/finally blocks are independent of each other. Your suggestion would look like this...<BR/><BR/>Try<BR/> Try<BR/> stuff<BR/> Except<BR/> Handle Bad things<BR/> end<BR/>Finally<BR/> Tidy up<BR/>end<BR/><BR/>On the exception, errors are handled, then passes to the finally to tidy up.<BR/><BR/>SteveSteve Peacockehttps://www.blogger.com/profile/03155137500284265720noreply@blogger.comtag:blogger.com,1999:blog-3782954984366933851.post-59320078196558841842007-08-31T03:32:00.000+12:002007-08-31T03:32:00.000+12:00As a relatively late returner to Delphi I'm annoye...As a relatively late returner to Delphi I'm annoyed you can't just do <BR/><BR/>Try<BR/> stuff<BR/>Except<BR/> Handle Bad things<BR/>Finally<BR/> Tidy up.<BR/><BR/>essentially in that order, you always seem to have to have the internal "try" bit, is that correct?<BR/><BR/>Apologies, as this bugs me coming from C#Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3782954984366933851.post-48391308707011649712007-08-15T13:13:00.000+12:002007-08-15T13:13:00.000+12:00Aargh! thanks Jolyn, that was meant to come out in...Aargh! thanks Jolyn, that was meant to come out in the change I did. It originally re-raised the exception, but I changed it. I'll update the post now.<BR/><BR/>Sorry, sadly I won't be there tomorrow. Another time.<BR/><BR/>SteveSteve Peacockehttps://www.blogger.com/profile/03155137500284265720noreply@blogger.comtag:blogger.com,1999:blog-3782954984366933851.post-59457007301783092542007-08-15T12:31:00.000+12:002007-08-15T12:31:00.000+12:00Hi Steve - I get that this is supposed to be a sim...Hi Steve - I get that this is supposed to be a simple example, but the example itself says that it is re-raising the exception when it isn't: It's destroying the exception and raising a whole new one.<BR/><BR/>Simple examples are only simple if they don't raise new [sic] questions.<BR/><BR/>;)<BR/><BR/>Off topic: Are you going to be at the Crowne Plaza tomorrow (Thursday?)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3782954984366933851.post-37002537614207976852007-08-13T13:38:00.000+12:002007-08-13T13:38:00.000+12:00Thanks for your observation Jolyon. While you may ...Thanks for your observation Jolyon. <BR/><BR/>While you may be correct in your statement (I certainly won't argue with your assertion on the change in the original exception), this was a simple situation. <BR/><BR/>My own code actually creates a MessageDlg, which most definately handles and removes the original exception, e.g.<BR/><BR/>MessageDlg(e.message + 'Receiving an error at this point may be a result of the cable becoming dislodged etc Blah Blah', mtError, [mbOK], 0);<BR/><BR/>Raising an exception in this case would create a similar effect to simply showing a MessageBox. In either case, the user (off site non-computer literate) may be informed of even a critical error so the real effect to the use of the application would be the same.<BR/><BR/>Please remember, this is a simple example of using both except and finally in the same block, not of the technicalities of the exception itself.<BR/><BR/>You do however point out a very valid point, perhaps for another discussion sometime. <BR/><BR/>Oh, and neither Satin himself, nor any of his spawn belong in my office :-) <BR/><BR/>Thanks again.Steve Peacockehttps://www.blogger.com/profile/03155137500284265720noreply@blogger.comtag:blogger.com,1999:blog-3782954984366933851.post-10006388210977572792007-08-13T12:10:00.000+12:002007-08-13T12:10:00.000+12:00No no and THRICE NO!!try :except raise Exceptio...No no and THRICE NO!!<BR/><BR/>try<BR/> :<BR/>except<BR/> raise Exception.Create(..);<BR/>end;<BR/><BR/>is the spawn of the DEVIL himself!!! Doing this hides crucial information about the original exception, most notably the address at which it occured, but also changes the class of the exception to bog-standard Exception which might be a CRUCIAL ERROR as far as any outer exception handlers are concerned.<BR/><BR/>(when I say "changes the class, I mean the effect, not the act. The ACT is to handle/suppress/destroy the original exception and raise a whole new one)<BR/><BR/>Sometimes this is legitimate, but if all you are doing is adding information to an exception message then you should:<BR/><BR/>try<BR/> :<BR/>except<BR/> on e: Exception do<BR/> begin<BR/> e.Message := e.Message + #13#13<BR/> + 'Some additional useful information about the exception.';<BR/> raise;<BR/> end;<BR/>end;Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3782954984366933851.post-80778349045229591012007-08-13T07:23:00.000+12:002007-08-13T07:23:00.000+12:00Gidday everyone,Well, that will teach me to quickl...Gidday everyone,<BR/><BR/>Well, that will teach me to quickly fire off a posting without reading it and then leave for the weekend. I have only just read my own posting for that day.<BR/><BR/>As you will have gathered from my last comment, code came from a real life example. However, that code belongs to the company I work for and I would not post their property on my blog. I quickly set up a very trimmed down example, too trimmed down it seemed.<BR/><BR/>I will change the post to give a proper example. Apologies to all.<BR/><BR/>To Anonymous - You are most welcome to post again but please limit your criticism to a tone that is not derogatory.Steve Peacockehttps://www.blogger.com/profile/03155137500284265720noreply@blogger.comtag:blogger.com,1999:blog-3782954984366933851.post-30228034667913032582007-08-12T08:37:00.000+12:002007-08-12T08:37:00.000+12:00This comment has been removed by a blog administrator.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3782954984366933851.post-21140394408833689932007-08-10T20:58:00.000+12:002007-08-10T20:58:00.000+12:00Absolutely correct. Of course in real life, there ...Absolutely correct. Of course in real life, there would have been more of a reason.<BR/><BR/>For example, in the piece that I used, there were several calls like the mythical DoStuffWithDevice, each possibly returning a different error message. Because these error messages can be confusing, or perhaps sometimes even wrong, I actually created a MessageBox type call with the original "e.message" plus some other detail that will allow the user to zero in on the actual fault (e.g. a disconnected cable).<BR/><BR/>But you are totally correct, in this case there would be no need for the try/except block and it was only placed there to show how they could be used together.Steve Peacockehttps://www.blogger.com/profile/03155137500284265720noreply@blogger.comtag:blogger.com,1999:blog-3782954984366933851.post-46213823428785925292007-08-10T19:53:00.000+12:002007-08-10T19:53:00.000+12:00HelloI think the code could be:var curSave: TCu...Hello<BR/>I think the code could be:<BR/><BR/>var<BR/> curSave: TCursor;<BR/>begin<BR/> curSave := Screen.Cursor;<BR/> Screen.Cursor := crHourGlass; <BR/> // Show hourglass cursor<BR/> try<BR/> DoStuffWithDevice; // will raise an exception if error<BR/> If not CloseConnection then // raise my own error<BR/> raise exception.create('Cant Close Connection');<BR/> finally<BR/> Screen.Cursor := curSave; // return the cursor to what it was<BR/> end;<BR/>end;<BR/><BR/><BR/>Because the<BR/><BR/> except<BR/> Raise; // re-raise the exception<BR/> end;<BR/><BR/>do nothingAnonymousnoreply@blogger.com