Capturing application wide exceptions.

Good afternoon,
Could anyone tell me if there is a way of capturing an unexpected exception in an application so that it can be handled elegantly rather than closing the application down. That is, an exception that has missed the usual exception handling.

Implement the App’s UnhandledException event.

And for more information:

@Kem Tekinay: the App’s UnhandledException event is only when Xojo is really screwed up.

@Dennis Lowe: I have a class called ErrorException that handles all exceptions. In every method and event I have

exception exc theException = new ErrorException(exc, currentMethodName)

The ErrorException classes analyses the exception and logs some stuff like the call stack. Then it opens a window so that the user can send with one click all session logs and crash logs to my ticket system.

Bob Keeney ( BKeeney Software) published a free module years ago that I still successfully use today. It has a window which you can use to report the error to your user and have them email the error to you. I don’t think it’s still on his web site, but you could ask about it.

I’m not sure if it’s kosher, but I put this code at the end of every method to trap any unplanned exceptions. The method passed the exception can: display it in a dialog, write it to an error log or send the error to a database, anything you need. In Modules and Containers the self.Title needs to be “”.

Exception err commonOS.doHandleExceptionWAD(err, CurrentMethodName, self.Title)

Just the nuisance and maintenance headache of putting that code in EVERY method.

@Roger Clary — You usually need to catch exceptions only in critical methods like the ones called directly by a user’s action. The end-user does not care exactly where something bad happened.

The exception’s stack will tell you where it happened anyway.

Stephane, I disagree. Exceptions will pop up in the most unexpected places and if your app doesn’t address the error, the user gets a bad impression of your app

The only time I get an UnhandledException is when there is no stack.

The only time I see no stack is when I raised the exception myself. And even then, I usually create exception subclasses that take the CurrentMethodName in the constructor to manually fill out the stack.

I’ll have to go play with this a bit…

I’ve tried generating a NilObjectException, KeyNotFoundException, and StackOverflowException, and each gives me a path in the exception’s Stack. This is in keeping with my experience.

Allow me to clarify my position here. You should absolutely handle exceptions within methods where appropriate, but adding a generic exception handler to every method is inefficient since App.UnhandledException already gives you a place to catch and report the exceptions you didn’t account for, and enough information to make the reports worthwhile.

I always argue that App.UnhandleException is the place to catch those exceptions you don’t expect and do something that might help you solve the problem. I say might because the debugging details available are paltry at best. Xojo’s framework doesn’t even bother to include a value in the message property most of the time.

But my controversial opinion is that you must still shut down when you receive an unhandled exception. The entire point is that your code wasn’t expecting it, so you have no idea the state of your application. Some chunk of code you were expecting to run was “cut off” early. The only sane thing you can do is log as much as possible and stop.

I have no idea why that would be controversial, unless “controversial” is the new “sane”.

Well for experienced developers, it probably isn’t controversial.

Many thanks for all the advice.

  1. Not sure how it is ‘inefficient’ except for my copy/pasting (it’s only a pain the first 10,000 times). Negligibly more code and processing.
  2. I get to see the name of the window (I have many) and the name of the method that had the error. If a user reports this info, I know exactly where the problem lies.

You don’t need to capture it within the faulty method to get that information. The exception.Stack has the name of the method and how the user got there, and WindowCount will tell you if there are windows open, and Window( 0 ) will give you the frontmost window. Heck, you can cycle through the windows to report ALL the windows that are open (which is what we do).

By doing it in App.UnhandledException, you also don’t have to worry about forgetting to put your custom code in each method.

I honestly can’t think of a good reason to put code into every single method. (“I’ve always done it this way” doesn’t count. :slight_smile: )