- a RealBasic exception (stack overflow, accessing a Nil Object, etc.)
- an OS exception (memory corruption, buffer overflows, invalid operations, etc.)
In most cases when a user encounters a RealBasic exception you can catch this and continue with your program execution. However, if the user encounters a RealBasic exception that you're not expecting, you can create a stack trace (also referred to as the call stack) to help you narrow this down. I'm not going to go into details about catching exceptions as Geoff's blog post explains it very well, but being able to receive a stack trace from your user(s) can help you locate the problem.
So what is a stack trace? In short, it's a stack of method calls. All apps begin at a main entry point and starting from there it calls other methods.
[ etc. ] [ Method2 ] [ Method1 ] [ Main ]
Knowing in which method the exception occurred will help you narrow down the issue. Great, so how do I get this stack information?
Since the exception isn't handled by your app, you'll probably want to record the stack information in App.UnhandledException. Consider this less than real world example:
Sub Window.Open() Call Test End Sub Sub Test() // This will cause a NilObjectException Dim f As FolderItem f.Visible = True End Sub Function App.UnhandledException(error As RuntimeException) As Boolean MsgBox Join( error.Stack, EndofLine ) End Function
When you build and run this app, assuming you enabled App.IncludeFunctionNames, you should see something like this appear:
Window1.Window1.test%%o<Window1.Window1> Window1.Window1.Event_Open%%o<Window1.Window1> : [additional stack trace snipped for brevity] : %main
As you can see, the output is a bit mangled, but being able to record the stack trace can help you track down the issue when debugging isn't possible.