Designing APIs with typed throws in Swift – Donny Wals

When Swift 2.0 added the throws key phrase to the language, people had been considerably divided on its usefulness. Some folks most well-liked designing their APIs with an (on the time) unofficial implementation of the End result sort as a result of that labored with each common and callback primarily based features.

Nonetheless, the language function obtained adopted and a brand new criticism got here up often. The way in which throws in Swift was designed didn’t permit builders to specify the kinds of errors {that a} perform may throw.

In each do {} catch {} block we write we have now to imagine and account for any object that conforms to the Error protocol to be thrown.

This submit will take a better have a look at how we are able to write catch blocks to deal with particular errors, and the way we are able to leverage the model new varieties throws that might be applied by means of SE-0413 just lately.

Let’s dig in!

The scenario in the present day: catching particular errors in Swift

The next code exhibits a typical do { } catch { } block in Swift that you simply would possibly already be accustomed to:

do {
  attempt loadfeed()
} catch {
  print(error.localizedDescription)
}

Calling a technique that may throw errors ought to all the time be executed in a do { } catch { } block except you name your technique with a attempt? or a attempt! prefix which can trigger you to disregard any errors that come up.

With a view to deal with the error in your catch block, you may forged the error that you simply’ve obtained to differing kinds as follows:

do {
  attempt loadFeed()
} catch {
  swap error {
  case let authError as AuthError:
    print("auth error", authError)
    // current login display
  case let networkError as NetworkError:
    print("community error", networkError)
    // current alert explaining what went unsuitable
  default:
    print("error", error)
    // current generic alert with a message
  }
}

By casing your error within the swap assertion, you may have totally different code paths for various error varieties. This lets you extract data from the error as wanted. For instance, an authentication error may need some particular circumstances that you simply’d wish to examine to appropriately handle what went unsuitable.

Right here’s what the case for AuthError would possibly find yourself trying like:

case let authError as AuthError:
  print("auth error", authError)

  swap authError {
  case .missingToken:
      print("lacking token")
      // current a login display
  case .tokenExpired:
    print("token expired")
    // try a token refresh
  }

When your API can return many various sorts of errors you may find yourself with numerous totally different circumstances in your swap, and with a number of ranges of nesting. This doesn’t look fairly and fortunately we are able to work round this by defining catch blocks for particular error varieties.

For instance, right here’s what the identical management movement as earlier than appears to be like like with out the swap utilizing typed catch blocks:

do {
  attempt loadFeed()
} 
catch let authError as AuthError {
  print("auth error", authError)

  swap authError {
  case .missingToken:
      print("lacking token")
      // current a login display
  case .tokenExpired:
    print("token expired")
    // try a token refresh
  }
} 
catch let networkError as NetworkError {
  print("community error", networkError)
  // current alert explaining what went unsuitable
} 
catch {
  print("error", error)
}

Discover how we have now a devoted catch for every error sort. This makes our code somewhat bit simpler to learn as a result of there’s so much much less nesting.

The primary points with out code at this level are:

1. We don’t know which errors loadFeed can throw. If our API adjustments and we add extra error varieties, or even when we take away error varieties, the compiler gained’t be capable of inform us. Which means that we’d have catch blocks for errors that can by no means get thrown or that we miss catch blocks for sure error varieties which suggests these errors get handles by the generic catch block.
2. We all the time want a generic catch on the finish even when we all know that we deal with all error varieties that our perform chilly in all probability throw. It’s not an enormous downside, nevertheless it feels a bit like having an exhaustive swap with a default case that solely comprises a break assertion.

Fortunately, Swift proposal SE-0413 will repair these two ache factors by introducing typed throws.

Exploring typed throws

On the time of penning this submit SE-0413 has been accepted however not but applied. Which means that I’m basing this part on the proposal itself which implies that I haven’t but had an opportunity to completely take a look at all code proven.

At its core, typed throws in Swift will permit us to tell callers of throwing features which errors they may obtain because of calling a perform. At this level it appears to be like like we’ll be capable of solely throw a single sort of error from our perform.

For instance, we may write the next:

func loadFeed() throws(FeedError) {
  // implementation
}

What we can’t do is the next:

func loadFeed() throws(AuthError, NetworkError) {
  // implementation
}

So despite the fact that our loadFeed perform can throw a few errors, we’ll have to design our code in a method that permits loadFeed to throw a single, particular sort as a substitute of a number of. We may outline our FeedError as follows to do that:

enum FeedError {
  case authError(AuthError)
  case networkError(NetworkError)
  case different(any Error)
}

By including the different case we are able to acquire a number of flexibility. Nonetheless, that additionally comes with the downsides that had been described within the earlier part so a greater design could possibly be:

enum FeedError {
  case authError(AuthError)
  case networkError(NetworkError)
}

This absolutely depends upon your wants and expectations. Each approaches can work nicely and the ensuing code that you simply write to deal with your errors may be a lot nicer when you’ve much more management over the sorts of errors that you simply may be throwing.

So once we name loadFeed now, we are able to write the next code:

do {
  attempt loadFeed()
} 
catch {
  swap error {
    case .authError(let authError):
      // deal with auth error
    case .networkError(let networkError):
      // deal with community error
  }
}

The error that’s handed to our catch is now a FeedError which implies that we are able to swap over the error and evaluate its circumstances straight.

For this particular instance, we nonetheless require nesting to examine the particular errors that had been thrown however I’m certain you may see how there are advantages to realizing which kind of errors we may obtain.

Within the circumstances the place you name a number of throwing strategies, we’re again to the quaint any Error in our catch:

do {
  let feed = attempt loadFeed()
  attempt cacheFeed(feed)
} catch {
  // error is any Error right here
}

When you’re not accustomed to any in Swift, take a look at this submit to be taught extra.

The explanation we’re again to any Error right here is that our two totally different strategies may not throw the identical error varieties which implies that the compiler must drop all the way down to any Error since we all know that each strategies should throw one thing that conforms to Error.

In Abstract

Typed throws have been in excessive demand ever since Swift gained the throws key phrase. Now that we’re lastly about to get them, I feel a number of people are fairly comfortable.

Personally, I feel typed throws are a pleasant function however that we gained’t see them used that a lot.

The truth that we are able to solely throw a single sort mixed with having to attempt calls in a do block erasing our error again to any Error implies that we’ll nonetheless be doing a bunch of switching and inspecting to see which error was thrown precisely, and the way we must always deal with that thrown error.

I’m certain typed throws will evolve sooner or later however for now I don’t assume I’ll be leaping on them right away as soon as they’re launched.