Tip: try..except..finally

[Blake]

Here's a tip. Hope you find it interesting:

In a lot of langauges, you can add some code that's to be executed no matter what happens in the rest of the routine. For example, if you had coded a freeze:

ui_freeze(.t.)
parentform.close()
vformname.Index_Set(vindexnamevalue)
vformname.show()
ui_freeze(.f.)

And something happened in between the freeze and the unfreeze, your user'd be stuck. So you'd write:

ui_freeze(.t.)
try
parentform.close()
vformname.Index_Set(vindexnamevalue)
vformname.show()
except
handleError("Houston, we have a problem.")
finally
ui_freeze(.f.)
end try

The A5 code that I've seen handles it this way:

ui_freeze(.t.)
On Error Goto ErrorTrap
parentform.close()
vformname.Index_Set(vindexnamevalue)
vformname.show()
ui_freeze(.f.)
end

ErrorTrap:
ui_freeze(.f.)
handleError("Houston, we have a problem.")

But this is cumbersome, especially if your clean-up code is extensive, not just a line or two.

However, I discovered you can accomplish the same thing by taking advantage of Xbasic's...em...laxity. :-)

ui_freeze(.t.)
On Error Goto ErrorTrap
parentform.close()
vformname.Index_Set(vindexnamevalue)
vformname.show()
if .f. then 'this code only executes if there's an error
ErrorTrap:
handleError("Houston, we have a problem.")
end if
ui_freeze(.f.)
end

In some Basics, leaping into a block wouldn't be allowed (the interpeter would be confused by the END IF because it hadn't encountered an IF in the first place) but this doesn't seem to bother Xbasic!

[Lenny Forziati]

RE: Tip: try..except..finally

The more typical way of writing this code would be:

ui_freeze(.t.)
On Error Goto ErrorTrap
parentform.close()
vformname.Index_Set(vindexnamevalue)
vformname.show()
ui_freeze(.f.)
end

ErrorTrap:
handleError("Houston, we have a problem.")
end

-Lenny

[Blake]

RE: Tip: try..except..finally

Hi, Lenny. Thanks for the comments.

I'm confused. You say "The more typical way of writing this code would be:" and then you give code that's almost identical to the code that I gave after saying "The A5 code that I've seen handles it this way".

Unless I'm missing something, we're in agreement about how it's usually done.

The point of doing it the way I suggest is to get the equivalent of a "finally" block: That way you don't have to code "ui_freeze(.f.)" and "tbl.close()" and whatever other finalization code you have in two places.

In your code example, in case of an error, the routine would exit leaving the user-interface frozen, unless I've missed something. The point not being that you meant to show perfect code, but that's the sort of thing that I might do by mistake in real code and not realize till I got the bug report. (And even then not necessarily be able to track down.)

[Jim Chapman]

RE: Tip: try..except..finally

Hello Blake,

This is interesting. Two issues come to mind, if you coded the routine the way you 'discovered', if a later version of Alpha Five tightened up the Xbasic, it might break this code.

On another note, the parentform.close() should be the last command in a script (assuming that the script is being played from a form event, button push, etc on the form) as the script runs in the memory context of the form. In essence this is trying to 'close down' the memory space the script is running in.

Interesting,

Jim

[Blake]

RE: Tip: try..except..finally

>

That did occur to me. On the other hand, since it's not trying to =return= from anywhere or continue a loop that hasn't been setup, it should be okay. If/Then/Else blocking is just straight branching, basically.

Even this solution is only partial; language support for exception handling would be better.

>

"Important safety tip. Thanks, Egon!" That would be important for anyone who wrote a script to know; it's not directly relevant to this kind of structure.

Although, upon experimentation, that doesn't actually seem to be true. For example:

dim S as C
S = "Hello, World!"
parentform.close()
trace.writeln(S) 'works

Maybe the context remains in existence until the script closes. That would make sense.

[Lenny Forziati]

RE: Tip: try..except..finally

Yes, my code is essentially what you wrote as your first example. I assumed your handleError() UDF would take care of unfreezing the UI, but now that I look closer at what you wrote, that was a bad assumption.

The (potential) problem with your second example, besides that it reduces readability a bit, is that it takes advantage of an unexpected behavior that neither you nor I would expect to work. If the Xbasic team "fixes" this in the future, your code will break and you'll have to spend the time to figure out why. It's dangerous to take advantage of a bug - I'm not saying this is or is not a bug because that's not up to me, but I would not be surprised if your second example would not work in a future release.

-Lenny

[Blake]

RE: Tip: try..except..finally

The (potential) problem with your second example, besides that it reduces readability a bit,

I would say that, once you were used to the convention, it increases readability. You know that an "If .F." block is exception handling code and that it's followed by finalization code.

but I would not be surprised if your second example would not work in a future release.

One of the hazards of working without a language definition. You don't know if what you're doing is supposed to work or not. A compromise, then: We label the finalization block and jump to it if execution has been normal.


ui_freeze(.t.)
On Error Goto Exception
parentform.close()
vformname.Index_Set(vindexnamevalue)
vformname.show()
Goto Finalization

Exception:
handleError("Houston, we have a problem.")

Finalization:
ui_freeze(.f.)

[Bill Parker]

RE: Tip: try..except..finally

My standard approach to this is to put error handling code after the END statement for the script, just as I would embedded functions.

ui_freeze(.t.)
On Error Goto Exception
parentform.close()
vformname.Index_Set(vindexnamevalue)
vformname.show()

Finalization:
ui_freeze(.f.)
END

Exception:
handleError("Houston, we have a problem.")
Goto Finalization

Bill.

[Blake]

RE: Tip: try..except..finally

Yeah, that's good, too. Arguably better since the exception code triggers the goto and contains the other goto, and is out-of-the-way so that the normal flow of the routine is apparent.

The key is not having to duplicate the finalization code.