Failure is Always an Option

The September/October 2010 edition of REALbasic Developer came out this week.  Marc Zeedar has additional information about the REAL Studio Web Edition and includes some details that I didn’t cover in my Web Edition blog post.

JC has an article on Trapping For Errors which is a good read.  Coincidentally, in my regular column I talk about how having a program fail can be instructive and how ‘failure is always an option’.

More information on REALbasic Developer Magazine can be found here.

In almost all of my applications I have an automated bug reporter class that allows the user to send me the Runtime Error type, the Error Stack and (hopefully) a brief description from the user on what they were doing.  It lives only in the App.UnhandledException event and nowhere else.  It’s far from perfect, but it’s better than nothing.

What do you have in your RB apps to get that crucial error information?

5 thoughts on “Failure is Always an Option

  1. I don’t need crucial error information. Unlike the rest of you, my programs have no errors at all and never fail. 🙂

    Seriously, an article on trapping for errors should be required reading for RB programmers, if not all programmers using any language. Most programs have inadequate error testing. I’ve gone back to examine my early code in Commodore VIC-20 and C-64 BASIC/assembly, and C/C++ on the Amiga and Mac. It had _no_error trapping code at all. I didn’t learn from program failures at all — I just cursed them and spent way too much time in the debugger searching everywhere for the bugs.

    My programming has improved through the years because I read tons of books on best programming practices and standards, QA, unit testing, refactoring and, when I was a Java programmer, exceptions. However, I’m a Type A personality (but if I work harder at it, I could make A+). All programmers need to constantly keep learning about areas of programming that they do not know, and improve their programming skills. Reading focused articles like those in RBJ and on RBLibrary can steer new and intermediate RB programmers down this path painlessly.

  2. During normal operation I log tons of stuff to a text-file living beside my application (if write permissions are present) or in the temp-directory. Most of the tricky stuff in the code is wrapped in a try/catch block but there is a App.UnhandledException function as the final destination, adding stack trace etc to the log-file and then asks the user for a location where to save the log-file (copy it from the location where it was created). The UnhandledException function also takes a snapshot of the screen and adds that to the file which has proven very good in many cases.

    The log-file is then sent to us for analysis and normally we add another try/catch block for the next version.

    For the interested, I have uploaded a sample log-file to

  3. There’s some great suggestions here but I notice a number of crashes don’t ever get caught by any exception handler.

    I store a temporary file that gets removed on quit. This lets the app know if it crashed on last run. I then grab the text in the most recent Apple crash log for my app and include that with all of the other info for the user to email in.

  4. @Scott Steinman Of course, under such old programming methods (Assembly/Machine Code, Forth, early dialects of Basic) there were no built in methods of error handling. OTOH since they were effectively linear, providing you used good techniques there was the possibility of starting at one end and working forwards to track down all possible bugs (more or less).

    However, with OOP yes some method of getting the bug data is needed. At the moment, since all my “production” software is in-house or with a couple of firms who know me personally, I simply have the generic App.Unhandled dump that puts the error into a text file next to the app, or displays it on screen for reporting back to support (Me). As I am shortly going to release some software to a wider market however I’m looking at some improvements on that, and I particularly like Stephen’s idea there.

    Another tip, apart from the usual filter all input, use try-catch etc, is I use an ResultReturn object which consists of a boolean (defined by global constant as Success and Failure), code, and friendly error text. This gets returned from functions that would otherwise be procedures that deal with database or file handling and reports any failures “up the line” to the calling function. Sometimes the failure is due to something we would anticipate, but sometimes it shows a subtle coding error, e.g. assuming that we have already created an object when the particular path the code has taken has missed all the usual creation points. It’s also shown up a couple of RB bugs too.

Comments are closed.