Getting better NSErrors from Swift 2's ErrorType

Cocoa has included NSError since version 10.2.7. It is the standard way of expressing and returning errors in Cocoa applications.

NSError is not just an object to be consumed by simple error handling code. It has many properties and associated APIs, particularly on macOS, that make it eminently suitable for presenting directly to users.

Since the introduction of Swift 2 it has been possible to throw Swift ErrorType instances and have them bridge automatically to NSError. Unfortunately this bridging behaviour is rather limited. ErrorType instances bridged to Objective-C APIs are very bare bone. They lack localised descriptions, failure reasons, recovery suggestions, help anchors and the like.

This might not seem so bad if you only develop mobile applications. Most iOS applications do not use features like error recovery or help anchors.

If you develop macOS apps, like we do, it is more of a problem. macOS has built in support for presenting rich error alerts using -presentError: on NSResponder or NSAlert’s initWithError:. If the NSError instance presented has a fully populated userInfo dictionary the user experience is greatly improved.

For example:

An NSAlert presented using a rich NSError instance.

As opposed to:

An NSAlert presented with just an instance of ErrorType

Although iOS does not come equiped out of the box to present NSErrors to users the way macOS does, you can easily create a similar system for NSError presentation in your own apps using UIAlertController, or some other custom transient or inline alert. We’ve done exactly this in iOS apps we’ve developed for clients.

The future is bright

Swift Evolution proposal SE-0112 describes how future versions of Swift will improve the bridging of Error (the new name for ErrorType) to NSError. This proposal addresses all of the limitations of the current bridging behaviour.

But for now, we have to fend for ourselves

However, in the meantime, we’re stuck with Swift 2 — initial beta releases of Xcode 8 and Swift 3 didn’t include an implementation of SE-0112 but recently it has been implemented (i.e., Xcode 8 beta 5 includes the new Error protocol).

Below I present a simple mechanism for extending ErrorType to bring richer NSError behaviour to your iOS and macOS Swift 2 applications.

NSErrorUserInfoValueProviding

NSErrorUserInfoValueProviding— A mechanism for providing NSError userInfo values for ErrorTypes.

This mechanism is not as sophisticated as the one proposed in SE-0112 but it does address some of the deficiencies in the existing Swift 2 ErrorType bridging behaviour. The NSErrorUserInfoValueProviding protocol above gives you an easy way of extending your ErrorTypes to include a localized description, failure reason or recovery suggestion.

Note

The code presented utilises APIs introduced in iOS 9 and macOS 10.11 — it will not work on earlier versions.

Based in Melbourne, Australia, Itty Bitty Apps builds great software on mobile and Mac for clients big and small. It also makes Reveal — Amazingly powerful runtime view debugging for iOS developers.