Summary
If an error occurs on a particular line of code, the error is often reported on a completely unrelated line.
Objo Studio Version
26.7.2
Operating System
MacOS
Steps To Reproduce
I stepped through the code with the debugger and what appears to happen.
1) Error occurs
2) Debugger steps to the start of the code block in which the error occurred, then, if applicable, to the start of the code block the triggering code block was in, and THAT line is reported as the source of the problem. The visual effect is as if the debugger has started stepping backwards rather than forward through the code, but what is doubtless happening is it's backing out through its execution contexts.
Expected Result
I would expect execution to stop and display the exception when it happens and then give me options, if any, let me examine the current stack trace, etc., or just stop execution there. I would expect the line where the exception happened to be reported if the debugger isn't running.
Actual Result
Execution does not stop, single stepping goes through the unwinding of scopes until apparently there are no more at least within the offending code unit. The line reported as the error site is the last line the debugger steps to after the error.
Screenshots, Logs, Or Sample Project
Here's a trimmed down example:
If _charInfoTable = Nothing Then
var cs As New CriticalSection()
Lock cs
Var stream As BinaryStream
Try
Var file As FileSystemItem = SpecialFolder.Resources.Child("Grommes").Child("MutableString").Child("chartab.txt")
stream = BinaryStream(file) # <= ERROR, missing New, so throws TypeMismatchException: Cannot cast 'FileSystemItem' to 'BinaryStream'
_charInfoTable = stream.ReadAllBytes()
Finally
If stream <> Nothing Then
stream.Close()
End If
End Try
End Lock
End If
return _charInfoTable
On the line where I indicate the error is thrown, the next place the debugger goes is Try, then Lock cs. That is where the debugger stops single stepping and that is where the error marker is placed.