FYI, here's the December 2015 discussion on typed throws: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003284.html
On Tue, Dec 27, 2016 at 4:57 PM, Tino Heth via swift-evolution < [email protected]> wrote: > Right now, we basically have "throws Error", and no matter what is > actually thrown, we can always catch exhaustive by keeping the statement > unspecific. > > > True, but for me it's more about knowing what a method can throw > > That's always possible if throw can be annotated with a list of errors; in > this case, it's up to the library author to be specific > > > myMethod(args:[String:Any]) throws IOError, IllegalArgumentError? { … } > > Imho to much confusion with no real benefit: > Shouldn't it be up to the caller to decide which errors need special > treatment? The library can't enforce proper handling at all. > > > Partly, but it's really just intended to distinguish things that are > genuine runtime errors, versus things that shouldn't have happened, > > That reminds me to much on the route Java took... > > If the distinctions not significant enough though then the "optional" > error types could just be ignored for now, I think the more important > ability is the ellipsis indicating "plus other errors" so we can specify > either exhaustive lists of error types, or keep them open-ended, in which > case the types listed are those that would be placed as catch blocks, with > the ellipsis indicating that a catch-all is still required (or throw on the > current method). > > That are three levels of error whereas one should be enough — and I'm > really not a fan of ellipsis: > Just require the list to be complete, which can always be achieved by > adding Error (or Any — imho we should remove the restriction that throwable > types have to conform to an empty protocol). > In this case, the meaning of the list would be more or less only > documentation (it's no restriction on what can be thrown), but that would > be fine for me, and it could be used for autocompletion as well. > > _______________________________________________ > 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
