Introducing the “Welcome to Xojo” Bundle!

New to Xojo and looking for guidance? We've put together a terrific bundle to welcome you! Xojo Bundle

This bundle includes six back issues of the magazine -- all of year 14 in printed book and digital formats -- plus a one-year subscription so you'll be learning all about Xojo for the next year. It's the perfect way to get started programming with Xojo. And you save as much as $35 over the non-bundle price!

This offer is only available for a limited time as supplies are limited, so hurry today and order this special bundle before the offer goes away!

Article Preview

Buy Now

Issue 11.3


Not Every Exception is a Bug

Exceptions can represent failures outside of a program's control

Issue: 11.3 (May/June 2013)
Author: Seth Verrinder
Author Bio: Seth is a consultant who uses Real Studio every day in his job at BKeeney Software, Inc.
Article Description: No description available.
Article Length (in bytes): 5,694
Starting Page Number: 72
Article Number: 11309
Related Web Link(s):


Excerpt of article text...

It's easy to think of exceptions as bugs and often that is the case. A NilObjectException is one example of an exception that always indicates a bug because it means that a variable wasn't initialized or some code used a function that might return Nil but didn't check the result (watch out for SQLSelect). But what about an IOException? If you try to write to a file and the disk fails causing an IOException that's not a bug in your program, it's a bug in the external world where your disk lives.

Separating Bugs from Failures

In my infinite spare time, one of the things I like to do is try out other programming languages. There are always valuable ideas that may be common in one language community but not so well known in others.

Recently I've begun playing with Clojure, a modern variant of Lisp. Rich Hickey, the creator of Clojure, gave a talk titled The Language of the System (see http://www.youtube.com/watch?v=ROor6_NGIWU). It's mostly about distributed systems and it's partly a lament that the tools we have inside our programs are much better than the tools we have to make programs talk to each other. But one statement he made stood out to me: he said "distributed error modes are the only error modes". What he meant was that the services a program depends on may not be available and that those dependencies represent ways that a system can fail that you need to deal with not as bugs but as failures that are outside your program's control. They are the real errors.

I think a similar distinction applies to exceptions in Real Studio. When you think about the types of exceptions that might occur and how to handle them, think about whether they represent a failure of something your program depends on (like a disk, network connection, or database).

Dealing with Failure

...End of Excerpt. Please purchase the magazine to read the full article.