At XDC 2019 my session was titled Xojo Design Mistakes (the alternate but way longer title was ‘Thankfully time travel doesn’t exist or my future self might travel back and murder my younger self for the stupid coding mistakes I’ve made’). These are things that I’ve discovered over the years, both in my own projects and in other peoples projects that are just plain wrong or less than ideal. This will be an on-going series since I had well over 50 slides and left about 150 out. So when I get bored I’ll bring these topics up.
Xojo has evolved over the years. Many of the global framework (the classic framework) classes set an error bit or error code when an error occurred and the developer has to check to see if there is an error and deal with it accordingly. Many developers don’t check – mainly out of ignorance, and that’s a problem.
The newer (but soon to be deprecated) Xojo framework (and we’ve been told the API 2.0 framework as well) throws Runtime Exceptions to report errors. The exceptions definitely get your attention because, well, an exception happened. The problem is that many Xojo developers don’t catch exceptions anywhere in their application. This results in dialogs like this:
Users hate seeing this and it’s unhelpful to the developer because it tells them NOTHING about the cause of the error. And, their application quits making the user really unhappy.
The Application object in every Xojo project has an UnhandledException event made to catch any exceptions not caught anywhere else. It’s declaration is this:
By returning True you can keep the application from quitting. Just returning true is just as bad, perhaps worse, than the first dialog because the app had an exception and the app might now be in an unknown state and the user has no idea that it happened. At this point what happens is anyone’s guess. Silent errors are a bad thing. Never do this.
A better way is to use the App.UnhandledException event to report that something happened so the user can decide what to do. Ideally, you’d like to get some information from them so the developer can get an idea of what’s caused the exception. What were they doing when the exception happened? What is the stack trace?
If you are are unaware of what the Stack Trace is this is the call stack your app is current in when the exception occurred. Maybe you called the Pushbutton1.Action that called ClassA.Method1 which called Global.MethodB which called Global.MethodC. This information (although not as neatly) is in the stack trace. It is sometimes invaluable in helping find and fix bugs.
BKeeney Software created a generic error reporting system years ago that when put in the App.UnhandledException shows the user a dialog like this when an exception occurs. You can tailor the message to suit your needs.
We generally don’t quit apps when exceptions are raised, but it is something that some clients want. The Report Error button then takes them to another dialog asking for more information. The user can easily bypass this section by pressing OK. Hopefully your users are nice and they’ll report the error.
If they select the E-Mail Bug Report or Save Text File button without putting anything in the TextField we present a dialog begging them for more information. Sometimes this works but not always.
Regardless, the next step in the process creates an email or text file. Sending an email requires the use of the computers built-in email client and we find this has advantages in that we get the users email address. A sample email goes something like this:
In our email we get the type of exception, the time, the method location, basic system information, the user description (hopefully), and the stack trace. A vast majority of the time that’s enough to find a bug. Sometimes it’s not but at least you can email them back. The text file still requires them to send it to us via email so we helpfully include the support email address.
If you want to play around with this example, please download it from https://www.dropbox.com/s/3uxyqvjf4wvjrpg/Exception%20Handler%201.0.zip?dl=0. Feel free to use in your own code however it is provided as-is with no warranty. We cannot provide support.
You need to implement something similar to this exception handling strategy. It will help your customers provide feedback to you so you can fix bugs. This seems like the least you should do. With the upcoming API 2.0 with API’s that throw exceptions rather than setting error codes this will be more important than ever. I’m sure I’ll talk more about Exception handling strategies once API 2.0 is released.
What other types of things do you do for error reporting?