Finding an unhandled exception

Does anyone have a good idea how to find a really unhandled exception?

When closing a window I get this lovely exception here:

  • Of course, there is an UnhandledException event in the app which should handle the exception. But that should show a nice window.
  • When I set a breakpoint in the Close event of the window then the exception is already shown. So the exception must occur somewhere below in the hierarchy. But the window has dozens of containers.
  • I tried to revert to a version from last week. But I get the exception there, too, in spite of having not changed much.
  • I only get the exception on High Sierra but not Monterey.
  • And to really spite me the app doesn’t even crash at all after the exception window is shown.

Output the stack() Array here?

Normally when this happens you’d want to try put some breakpoints and see after which it’s more likely to happen to narrow things down. We just ask the user to send it to the developers (including the stack etc).

What do you mean with “stack() Array”?

I have a session log:

2021-12-20 11:38:18 DBWindow.ShowSetup done
2021-12-20 11:38:18 CCEmailView.Reset
2021-12-20 11:38:18 CCEmailView.LoadAccounts
2021-12-20 11:38:19 CCFormatServer.bbConnect.Close
2021-12-20 11:38:19 CCEditAccount.bbCheckImap.Close
2021-12-20 11:38:19 CCExportFolder.Close
2021-12-20 11:38:19 CCFormatFilemaker.Close
2021-12-20 11:38:19 CCFormatValentina.Close
2021-12-20 11:38:19 CCFormatPDF.Close
2021-12-20 11:38:19 AppleListbox.Close
2021-12-20 11:38:19 CCEmailView.myClose
2021-12-20 11:38:19 CCOptionsView.myClose
2021-12-20 11:38:19 CCDataView.myClose
2021-12-20 11:38:19 CCDeleteView.myClose
2021-12-20 11:38:19 CCStackView.myClose
2021-12-20 11:38:19 CCPlanList.Close
2021-12-20 11:38:19 CCAccountList.Close
2021-12-20 11:38:19 CCEditAccount.Close
2021-12-20 11:38:19 CCPlanHeader.Close
2021-12-20 11:38:19 CCScheduler.Close <--------- Exception must have occurred here
2021-12-20 11:38:33 DBWindow.doQuit is scheduler: false
2021-12-20 11:38:33 DBWindow.CloseArchive

But the window has a lot containers with multiple levels of them.

In App.UnhandledException you can read the err.Stack() AS String please print that here.

No can do.

This is not a custom message i guess this message is from Xojo’s App.UnhandledException event ?

No, the App.UnhandledException event has code that isn’t reached:

globals.theErrorLog.LogItem "unhandled exception!!!"

'raise error
dim theErr as new ErrorException(error, "", "", "A really unexpected error occurred!")
#Pragma Unused theErr

'show the error report window

As DerkJ said, try to see what you get in the stack, I get as well nasty errors like that randomly and find some eventually but not all but the stack helps to point at least the location, you need more details than that . I have the feeling that App.UnhandledException is not always firing as I get cases where same as you have code there but it never reaches that, I just remember that you need to return a true or false to break the app and get the rest

Yes, that’s the case here. I’ve done a full checkout of the SVN for the last known good version. I need to wrestle with the SVN to overwrite the bad commits. Then I’ll do the changes again one by one.

1 Like

Since App.UnhandledException isn’t firing - something I find unusual, but I’ll take your word for it - you’ll need to use Try/Catch to find the exception. Wrap it around the close statement. If this happens when closing the window using the close box, consider adding a button to the window temporarily:

Sub PushButton1_Action()
  Catch Err As RuntimeException
    // Look at Err here
  End Try
End Sub

This should catch any deeper exception, and the stack property of Err should give you some clues.

1 Like

i guess you access a ui control which is not there anymore.

some other nil objects occur if u use a method or property at a nil object.
somehow Nil.DoSomething Nil.Text = “”

Good idea.

Yes, that’s probably the reason for the NOE.

Ok look for runtimeexception (catch all) handlers (end of methods) that may not be forwarding the exception or look for the text (parts) of the messagebox you getting.

Any reason you’ve not tried the simple “break on exceptions” menu item so Xojo breaks at the correct place?

I have worked in Realbasic, RealStudio and Xojo. “Break on Exceptions” always has been on.

Certainly, but you’ve not mentioned what happens with your exception; does it even break?

1 Like

No, it doesn’t break. The app doesn’t even quit.

use temporary in much methods at top System.DebugLog CurrentMethodName
u will know where the app was last

1 Like

The window has 2 dozen container, more than 40 classes and hundreds of methods.

start within the bounds of possibility :slight_smile:

1 Like