Question: How to Not use the Finally statement

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.

1 Like

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?

1 Like

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.

1 Like

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.

1 Like

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.

1 Like

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.