Returning Errors in Swift

Swift’s rich enumerations open up new possibilities for returning error information from functions. For example, for years Cocoa has had a convention whereby errors are returned via an out-parameter of type NSError. For example :

func executeFetchRequest(_ request: NSFetchRequest!, error error: NSErrorPointer) -> [AnyObject]!

What this method signature means is : If the method returns something, then the method succeeded and the returned something is an array; else, if the address of an NSError object pointer was supplied, make it point to an object that describes whatever error occurred. Sounds kind of like an enum to me.

Within application code, where Objective-C compatibility isn’t a concern, Swift will allow us to do this :

enum MyFetchResult
{
    case Success([AnyObject])
    case Error(NSError)
}

func myExecuteFetchRequest(_ request: NSFetchRequest!) -> MyFetchResult

...

switch (myExecuteFetchRequest(myRequest))
{
    case .Success(let results)
        // do something with results
    case .Error(let error)
        // do something with error
}

This approach has the advantage of avoiding polluting function signatures with redundant NSError arguments. Of course it does so at the cost of complicating the function result; however I think this approach will be somewhat less error-prone, especially if the function result is fed to a switch statement (like in the example above), which requires all possible values of the enum to be handled.

Retour sur les prévisions

Maintenant que j’ai eu le temps de digérer les vidéos de la WWDC (pas tous quand même!), voici mon auto-évaluation de mes prévisions :

  1. J’ai eu raison qu’Apple permettrait aux développeurs tiers de créer des modules, et aussi que ceux-ci serviraient entre autre à réduire les collisions de noms. Par contre j’ai prédit aussi que ces développements se feraient « à pas de tortue », ce qui n’a vraiment pas été le cas! Heureusement, je n’ai pas prédit qu’Apple ne présenterait pas un nouveau langage de programmation …
  2. Je n’ai pas eu raison par rapport au cryptage des données téléchargées en arrière-plan. NSURLSession permet de spécifier des NSURLProtocol maison — ce qui aurait pu être la porte d’entrée du cryptage — mais seulement pour les sessions qui ne sont pas en arrière-plan. Peut-être l’an prochain …
  3. On peut dire que j’ai eu raison sur la « profondeur » des changements dans l’interface utilisateur de OS X. Je pense que les applications existantes peuvent s’adapter au nouveau look sans avoir à changer leur code de façon significative.