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.

Prévisions WWDC 2014

J’ai quelques modestes prévisions de ce qui sera annoncé cette semaine à la conférence de développeurs Apple. Contrairement à ce que font la plupart des prognosticateurs, je m’en tiens surtout à des choses plutôt bas-niveau.

  1. Apple continuera à améliorer à pas de tortue son support pour le développement «in the large». Plus précisément, je pense que le concept de module, introduit l’an dernier, sera amélioré de façon à permettre aux développeurs tiers d’en créer. Je pense aussi que les modules serviront éventuellement (mais pas nécessairement cette année) à isoler les symboles applicatifs de ceux de l’OS. Cela réduirait les collisions (noms de classes, sélecteurs, etc) qui sont la source de biens des soucis sur iOS et OS X.
  2. NSURLSession sera amélioré pour permettre le cryptage des fichiers téléchargés ou téléversés en arrière-plan. Actuellement ces fichiers ne sont pas encryptés, ce qui empêche l’utilisation de cette technologie dans des domaines ayant de fortes exigences réglementaires tels que la finance et la santé. C’est le seul maillon manquant de la chaîne, car les donnés peuvent être cryptées (via SSL) sur le fil, et elles peuvent l’être aussi dans des fichiers créés directement par l’application.
  3. S’il y a cure de jeunesse pour l’interface utilisateur de OS X, je pense que ça sera plutôt superficiel. Le look va changer, mais pas les APIs en arrière. Le contraire serait difficile à justifier côté coût-bénéfice, à mon avis.