Skip to content

The New Xojo Framework: Ch-ch-ch-ch-changes

Published April 14, 2015 by Geoff Perlman

In the ideal world when you do something, you do it right the first time. In the real world, we learn more each day and what seemed right yesterday, a month ago or a few years ago, may no longer be right today. Xojo has been around for a long time now and in all that time we have learned a thing or two. One of the things we have learned is how to deal with errors.

Bowie_Changes.pngCh-ch-ch-changes (turn and face the strain) – David Bowie

As you have read in previous blog posts, we are building a new framework to clean things up. We refer to the current framework as the “Classic” framework and the new one as the “Xojo” framework. The Xojo framework was introduced four months ago with our support for iOS and at that time was limited to iOS projects only. With today’s release of Xojo 2015r2, we have added a lot more functions to the Xojo framework, all of which are now supported for the desktop and web in addition to iOS.

Previously, there were different ways to deal with errors depending on what part of the Classic framework you were using. For example, if you passed a string to the Val function, it would return zero if the function started with a non-numeric character. Pass Val the string “123$” and you’ll get 123 but pass it “$123” and you’ll get 0. Use the Left function to get the 5 leftmost characters from a string that has only 4 characters, and it will return those 4 characters. These may seem like reasonable results to return given what was passed in. But there are downsides to them.

There are three problems with handling errors in this way. First, they are all different so you have to learn different ways to handle different errors. Second, they are behaviors rather than actual errors and third (and most important), they allow code to pass along a value that could be legitimate without the user knowing it’s an error at all. This can create hard to find bugs. For example, say you are importing sales data from a text file. One of the thousands of values you import has a dollar sign at the front. This results in a zero when passed to Val. If zero is a potentially legitimate value, this error could easily be over-looked.

In the new framework, this won’t happen. Instead of using Val to convert text to a number (integer), you use the FromText function. Your code looks like this:

Sales = Integer.FromText(QuarterlySalesImportedValue)

If QuarterlySalesImportedValue cannot be converted to a number (because it starts with a non-numeric character like a $), rather than return a zero, a BadDataException exception is thrown. While the Classic framework has many different ways to handle errors, the new Xojo framework uses exceptions exclusively for reporting errors, making it more consistent.

In the Classic framework, detecting an error like this means converting the text to an integer then back to text and to compare it with the original value to see if they are the same. If they are, great. If they aren’t, then there was a non-numeric character in there. In the Xojo framework, you don’t worry about it and check for an exception.

If you haven’t used exception handling in your code before, don’t panic. It’s really not a big deal. An exception means that something unusual has happened and in most cases the app (or at least the function of the app the user is using) can’t continue. To use an exception you wrap the block of code that might result in an error in a Try…Catch statement. If an exception occurs, the code will call the exception handler (the catch portion of the Try…Catch statement) and deal with the error. Here’s an example:

Try
  'code to open the file and read the data here
  i =  Integer.FromText(ImportedQuarterlySalesData)
  'code to deal with the converted value here
Catch err As Xojo.Core.BadDataException
   Beep
   MsgBox "The import can't continue because the sales data is bad."
End Try

In this example I’ve left out the code you’d write to open the file, read in the data and do something with it, but you get the idea. In the new Xojo framework, all the functions that deal with opening and reading files throw the same BadDataException if something goes wrong, a single Try…Catch can handle it all. And of course you could choose to make the error message more specific, telling the user what row the bad data came from and showing them the bad data itself so they can go fix the data file. Exceptions also potentially remove lots of IF statements that often litter code checking for error conditions.

When it comes to errors, luck favors the prepared. Write your code so that it anticipates errors properly and handles them rather than waiting for the user to report that your software doesn’t work. In the new Xojo framework we are making it easy for you to do this by consistently using exceptions to report errors. They don’t require more code than using IF statements and in many cases, require less code and make your code easier to read.

We’ve added a lot more functionality to the new framework in 2015r2 allowing you to write most of your non-GUI code using the new framework and share that across all project types. For example, we have:

You’ll find that most of these classes work very similarly to those in the Classic framework. Click the items in the list above to review them. And these are just the new Xojo framework functions. We’ve added more to our iOS support as well.

When using the Xojo framework with your existing Classic code, you’ll need to use the new Using command or include the namespace with each function. I think you’ll find Using to be a better option. You can also use it for an entire class, module or window by right-clicking on the project item then choosing Add To -> Using Clause. Once the Xojo framework is complete, there will be a way to use it without bothering with Using at all.

We’ve made a lot of progress on the Xojo framework for 2015r2 which provides you with a more consistent and thus more productive experience. Yes, there will be a few new things to learn but there’s also a lot of great, new functionality as well. Over the years, we have had to write a lot of this functionality ourselves or use third party libraries. So much of what is needed is now built-in to the OS so in the Xojo framework, we can now call the OS functions directly. That means your Xojo apps pickup more functionality automatically without you (or us) having to do additional extra work. It also means that when bugs are fixed at the OS level, your apps automatically become more reliable without having to recompile them.

Published in Technology