[swift-evolution] Move placement of 'throws' statement

[Xiaodi Wu]

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 <
swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161227/d3993405/attachment.html>