Hi Fernando, Some projects use a result type to unify the error handling. https://github.com/antitypical/Result <https://github.com/antitypical/Result>
There has been discussions about this and Chris L thinks that we may get a native (constrained) result type at some point. https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/007858.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/007858.html> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/008057.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/008057.html> I can see a future where these get unified but the main issue imo is cocoa compatibility. Probably swift 5+ Cheers!, J. Cheyo > On Aug 5, 2016, at 4:50 PM, Fernando Rodríguez via swift-evolution > <[email protected]> wrote: > > Hi, > > I do a lot of training and one of the features of Swift that seems more > confusing to students (and myself) is error handling. There are too many ways > of doing it, and none seems satisfactory. > > Let's take for example an initializer. There are 2 different ways of handling > errors within an init: > > a) Old School: return nil. This was very simple in Objective C, because the > uncommon case of an error could be easily ignored...until everything crashed. > > In Swift it's not easy (nor advisable IMHO) to completely ignore the > possibility of an error. Besides, it has 2 complications. > > First of all, you return an Optional, and Optionals have a tendency to go > viral. Suddenly, all your code has to deal with optionals. > > Secondly, you have no information about the error itself. > > b) do/try/catch > > This allows you to have information about the error, but also causes the > newly created object to be "trapped" inside a do block. > > Are there any plans to address this situation? I believe there should be a > single, obvious and convenient way of handling errors in the language. > > What do you guys think? > > > > -- > > > > <http://keepcoding.io/es/> > > Fernando Rodríguez > m. +34 610 965 332 > t. +34 91 629 57 61 > fernando@k <mailto:[email protected]>eepcoding.io <http://eepcoding.io/> > > KeepCoding.io > 2120 University Avenue, Berkeley, CA > > Avda. Fuencarral, 44, Ed. 8, Loft 30 > 28108 Alcobendas (Madrid) Spain > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
