What I don’t like about the new Swift error handling model

I mentioned the new Swift error handling in my WWDC first impressions post. And although it’s true that I still have not had the opportunity to use it in a real project I’ve been playing with it in playgrounds :P

So let’s explore the two different approaches in this post.

We define a custom error enum so we can have information about the error.

enum MyError: ErrorType {
    case 💣
    case 💔
}

we can return a Result.Failure with an instance of our custom error.

enum Result<T, E: ErrorType> {
    case Success(T)
    case Failure(E)
}


func explodeResult() -> Result<String, MyError> {
    return .Failure(.💣)
}

let explosion = explodeResult()

The good part of working with a Result type is that we can leverage the compiler to enforce that the error cases are handled. If we want to print the result of the Explosion we have to unwrap it from the Result.

switch explosion {
case .Success(let explosion):
    print("It has been an awsome explosion \(explosion)")
case .Failure(let error):
    switch error {
    case .💣:
        print("I think we killed ourselves")
    case .💔:
        print("Uops, for ever alone")
    }
}

Now, if we don’t care about the error at all we still can ignore its value, just don’t implement the nested switch. We can even avoid switches at all with some extension to the Result type, but this could be something that the language could provide.​explosion.value.map { print(“It has been an awsome explosion ($0)”) }​

Using new Swift Error Handling Model

func explodeThrow() throws -> String {
    throw MyError.💔
    return "Yeee 👏🏻"
}

do {
    let text = try explodeThrow()
    print(text)
} catch MyError.💣 {
    print("I think we killed ourselves")
} catch MyError.💔 {
    print("Uops, for ever alone")
} catch (let error) { // THIS WILL NEVER HAPPEN
    print("Some error: \(error)")
}

I can agree that it gets nicer if you don’t care about the specific errors, or if you just want to bubble up with throws, but in this last example you can see the part that I don´t like about this.The compiler cannot help us when handling the error. I have a catch that will never happen. And I have to read the documentaiton or know the implementation to know wich error cases I have to deal with. For me it feels like the oposite of what the Swift type system is trying to give us.​As I said, I’ve still not tried this in a real project. I recommend you to read this post by @bradlarson to see the nice things about this model and how well it replaces the Cocoa model. At the end of it he also agrees with what I’ve tried to express with this post, and to be honest if the Swift team implements the suggestion I will not have anymore complains about this :P​Download the Playground.