un|we|sen

If you’ve developed Android apps, chances are you’ve written some Activity that displays a list of stuff. If you’ve done that, chances are, you’ve filled the list with data from a database cursor. If you’ve done that, chances are you created the Cursor by querying a content URI, which in turn invokes a ContentProvider.

So how do you handle errors with that?

To put that question into context, let’s look at some common things to check on a Cursor variable, and what they mean semantically:

1. When calling a function that returns a Cursor (such as database query functions), the return value could be null. That signals an unspecified error on the part of the function.
2. The Cursor object may have a row count of zero. Does that mean there was an error fetching data, or does it mean the data set is empty? Two different things.
3. The function may throw an exception instead of returning a Cursor. That’s pretty cool, but Cursors are often used in conjunction with a ContentProvider, which may or may not run in the same process as the calling code. As yet Android is unable to propagate exceptions across processes.

In other words, as cool as it might be to use Cursors as the standard data interface for filling lists of stuff with, well, stuff, their interface really doesn’t lend itself to good error handling. And good error handling is at the root of stable software.

Read the rest of this entry »