Catch Exception Missing the Ball?

I sometimes get bug reports from my users that my app crashed on a specific method with a nil object exception. However that method has a exception catcher that reports it and deals with it. But the pitched exception sometimes seems to not be getting caught?

Is this a known issue? I assume that if this method calls another method that raises an exception, the exception handler in this method should catch it.

I think I’m going to get a t=shirt that says

“Nil objects happen.”

Exception err As RuntimeException If err IsA EndException Or err IsA ThreadEndException Then Raise err End If // Do reporting/cleanup

Can you post the entire method?

Sure. All these are controls or subclassed controls. It’s unlikely but not impossible for something to be nil. However it’s odd that the exception doesn’t catch it.

[code]If app.IsQuiting Then Return

Dim currentView As ViewData = uistate.GetCurrentState.ViewData

lbheader.Visible = False

// Move Sessionbox
If currentView.ShowFilters Then
// Move down to make way for filters
TheReportsContainer.Visible = True
theGraphAndLegend.Top = + SegmentedChooser.Height + 92 // Move graph out of the way of report controls = + SegmentedChooser.Height + 92

// Listbox top aligns with graph top

theGraphAndLegend.Top = + SegmentedChooser.Height + 20 = -3
TheReportsContainer.Visible = False
End If

// Set bottom of graph
theGraphAndLegend.Height = Self.TrueWindow.Height -

// Sessionbox wide and showing details? Hide graph
If currentView.ShowDetails = True Then
TheGraphAndLegend.Visible = False
TheGraphAndLegend.Visible = True
End If

If currentView.ShowDetails = True Then
// Show wide over top of invisible graph
SessionBox.width = theGraphandLegend.Left + theGraphandLegend.Width - SessionBox.Left
// Summary with graph
SessionBox.width = theGraphandLegend.Left - 20 - SessionBox.Left
End If

lbheader.Visible = True

Exception err As RuntimeException
If err IsA EndException Or err IsA ThreadEndException Then
Raise err
End If

debug.Warning CurrentMethodName, 3, err


And FYI, here’s the stack being called

[code]Full stack trace:
-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
-[NSApplication run]

Verbose stack trace:
2 OfficeTime 0x0000000103011614 App.Event_UnhandledException%b%oo + 4100
3 OfficeTime 0x0000000102bbc40b Application._CallFunctionWithExceptionHandling%%op + 475
4 XojoFramework 0x00000001049764bb _Z33CallFunctionWithExceptionHandlingPFvvE + 262
5 XojoFramework 0x00000001047f12a2 _Z29CocoaFinishApplicationStartupv + 2076
6 AppKit 0x00007fff3519175d -[NSApplication run] + 699
7 XojoFramework 0x000000010497482d RuntimeRun + 42
8 OfficeTime 0x0000000102cc8a23 REALbasic._RuntimeRun + 19
9 OfficeTime 0x0000000103fb1cd8 _Main + 536
10 OfficeTime 0x0000000103f9be03 main + 19
11 libdyld.dylib 0x00007fff64d80085 start + 1

When are you executing your code? Do your controls already exist? Have you tried to do your code in a timer a couple of ms later?

When the interface receives a signal to change state, it does a Xojo.core.timer.callLater(0) to this method. (Mostly to stop flicker on Windows.)

It might be trying to call after the window has been closed despite me cancelling the call on CancelClose. I’ll be a bit more aggressive in my nil checking.

If there’s a calllater that refers to a control that has now been closed then you can get this effect

@Stephen Dodd — Does the exception appears on quitting the app? Because you use “if app.IsQuitting” at the beginning and I have seen many cases where the App object would become nil while the app is quitting and so, “if app.IsQuitting” would raise a NilObjectException (possibly in a non-catchable way, I don’t remember if it was the case for me).

As a workaround, I usually use:

If App=nil OR App.IsQuitting then....