I just realized the “Finally” block or statement. I can’t find anything mainly because everyone writes “And finally this happened”
I also read the LR about it and it seems good.
What do people use Finally for?
I just realized the “Finally” block or statement. I can’t find anything mainly because everyone writes “And finally this happened”
I also read the LR about it and it seems good.
What do people use Finally for?
Sub Open() Handles Open
MsgBox "test"
Dim r As New RuntimeException
r.Message = "Test"
Raise r
Finally
MsgBox "finally"
End Sub
The finally block will run, even if there was an exception in the method.
Great to set an IgnoreEvents flag to false if you set it to true on method beginning.
Thanks. That’s the sort of tip I was looking for.
Currently I put a lot of stuff in nested If statements and I can possibly remove a lot of nests
Warning from Norman: Finally may not run if you catch the exception.
So I may change code like this:
Sub Open() Handles Open
InsideOpen = true
MsgBox "test"
Dim r As New RuntimeException
r.Message = "Test"
Raise r
Catch noe As NilObjectException
InsideOpen = false
Return
Finally
InsideOpen = false
MsgBox "finally"
End Sub
I thought the Finally statement was only used with a try/catch block.
Interesting…
Learn something new every day…
#Pragma BreakOnExceptions Off
Dim s As String
Try
// Do something here, even something that can break
Raise New RuntimeException // Something broken
Catch e As NilObjectException
s = "A Nil Object Exception occurred"
Break
Catch e As OutOfBoundsException
s = "If some index was wrong"
Break
Catch e
// Catch any Exception
s = "Any other exception here"
Break
Raise e // Done, but let's re-Raise this exception
Finally
s = "The exception raised before won't act here"
s = "This will run in any case, even in case of any exceptions before"
Break
End
// The reraised exception will occur here, before the next line, but after the "Finally"
Break
s = "How could I intercept the last exception? Nest the last Try-Catch inside another Try-Catch"
Break
#Pragma BreakOnExceptions On
Nope. I’ve read Norman’s comment. Finally is not executed if you RETURN from the guts of the Try-Catch. Xojo does not intercept that.
c.f. Christian S
“Warning from Norman: Finally may not run if you catch the exception.”
Thank you. It’s something one should expect, but good for the reminder in planning.
Nope. Finally will run always, catching or not. The problem exists if you RETURN before it.
I’ve never used a Finally
block. I always just use
// Starting Code
Try
// Inner Code
Catch Err As WhateverException
// Exception Code
End Try
// Ending Code
I could put // Ending Code
into a Finally
block… but why?
Let’s suppose you start your try allocating resources, or writing buffered things that MUST BE released or flushed at end even if some exception occurs. “Finally” is the place to do it, because it will run, and something on the outside won’t.
I’m not sure what you mean. Something on the outside will run. In the example, // Starting Code
, // Inner Code
, and // Ending Code
are guaranteed to run, short of a Return
. The Catch
and Finally
blocks don’t have special access to variables created inside the Try
block either. So I can’t see what advantage Finally
has over just putting code after the End Try
statement. Code organization maybe, but that’s all I can see.
For Thom
Just being clear, the Finally section can be used in any routine, and doesn’t necessarily need a Try-Catch.
If you don’t catch your exception, or even worse, one of your catch interceptions causes another exception, your outer code will never run, your program will end. With a finally, even crashing after the block, the finally will run. That can be the difference of you finding a file with 0kb after a crash and a file with 4kb of important content saved.
I like Finally even more.
Ah I see what you’re saying. It’ll fire for an exception you didn’t prepare for. That’s why I don’t find a use for it, my unhandled exceptions always stop my applications. You can’t trust the state of the app after an unhandled exception.
Nope! It’ll fire always! Prepared or not, handled or not.
Try
// opening things
// risk things
Catch
// fixing things
Finally
// closing things
End
Is finally mandatory? No! When you don’t need to guarantee to finish something, that’s simply omitted as:
Try
// risk things
Catch
// fixing things
End
I understand that. But that’s what sets it apart from just using post-block code.