Swift ErrorTypes - A Modest Proposal

After the WWDC announcement, when I got over my initial knee-jerk ‘Exceptions - ick!’ reaction, I came around to being a supporter of the Swift 2 error handling model. While it would be nice to be able to desugar the implicit result type, and there’s a glaringly obvious hole with async error handling, for general failable synchronous calls it works well. However, there’s one aspect that really bothers me. Consider the following code:

enum MathError: ErrorType {
    case DivideByZeroError
}

func divide(l: Int, _ r: Int) throws -> Int {
    guard r != 0 else { throw MathError.DivideByZeroError }
    return l / r
}

func calculate() {
    do {
        let result = try divide(10, 2)
        print("Result = \(result)")
    } catch MathError.DivideByZeroError {
        print("Can’t divide by zero!")
    } catch {
        // this should never happen
        break
    }
}

Errors thrown by a function are completely untyped, so Swift is unable to infer that the first catch clause is exhaustive - this means you ALWAYS have to include a catch-all at the end of your do block if you want to completely handle the error. This isn’t just a case of redundant code - if you add an error case later on, you’re going to suddenly (and silently) hit your ‘This should never happen’ handler, which is probably not what you’d expect (and seems out of step with the way switch statements work).

The other problem is that we have no idea from the function signature what errors we should be trying to catch. Apple introduced a Throws: keyword in the doc comments, but relying on the original developer to keep comments up to date can be... ineffective.

A number of people have proposed that throwing functions should be declared with a list of all the types they can throw, rather like Java’s checked exceptions. This will nicely solve our divide function example:

func divide(l: Int, _ r: Int) throws MathError -> Int {
    guard r != 0 else { throw MathError.DivideByZeroError }
    return l / r
}

func calculate() {
    do {
        let result = try divide(10, 2)
        print("Result = \(result)")
    } catch MathError.DivideByZeroError { // this catch is exhaustive
        print("Can’t divide by zero!")
    }
}

Which is great - we now have a sensible exhaustive catch statement, we’ll get helpful compile errors if we add a MathError case and forget to handle it, and the function definition is clearer and self-documenting. However, this is a fairly simple case, and the problems with checked exceptions were always much more evident with larger & more modular codebases - for instance, we’d start to see functions like:

func openDatabase(path: String) throws libuvError, URLFormatError, ZipArchiveError, SQLiteError -> Database {

Technically in this case we’d still be able to write an exhaustive catch without using a catch-all, but I can give a rock-solid guarantee that no-one ever will. A function signature like this leaks internal implementation details, and the exposed error types are very unlikely to be useful to API consumers.

Additionally, this can have an invasive impact on the rest of the code - consider the scenario where these error types are annotated on all functions that call openDatabase, then all the functions that call those functions, and so-on up the line until we have a monster catch (all) block. Now imagine we update our database code and add a new ErrorType, or change the zip library and that ErrorType is now different. We could end up having to touch a dozen files to cover a semantically unimportant change. It’s also worth noting that the Swift team have explicitly said they don’t want “pedantic lists of possible error types, like Java”.

Now this is a somewhat pathological case (although I have seen a lot of Java code written like this in the past!) and hopefully ‘good developers’ wouldn’t write code this way. The way this problem should be solved would be either:

1. Erase the typed error information that’s not useful to consumers and just throw an untyped ErrorType - this brings us back full-circle - or
2. Translate the internal errors into a meaningful new ErrorType, such as:

enum DatabaseError: ErrorType {
    case InvalidPath(message: String)
    case CorruptDatabase(message: String)
}

Ultimately, the more I’ve thought about this, the less useful a list of multiple ErrorTypes seems to be. However, I think there’s still value in being able to (optionally) annotate a single custom ErrorType, as in the case of the MathError or a consolidated DatabaseError from our openDatabase call. So my Modest Proposal is stated thus:

// allow us to do this:
func myFunction() throws -> Int

// or this:
func myFunction() throws CustomError -> Int

// but not this:
func myFunction() throws CustomErrorOne, CustomErrorTwo -> Int

A single custom ErrorType is much closer to the underlying language model, neatly complements the Swift 2.1 function covariance, delivers most of the benefits of typed errors, and limits the damage that slovenly error propagation can do to the codebase.