[swift-evolution] Proposal: Typed throws

Andrew Bennett cacoyi at gmail.com
Mon Dec 7 18:38:39 CST 2015


Then let's change my response to simply: :+1:

Thanks!

On Tue, Dec 8, 2015 at 11:28 AM, David Owens II <david at owensd.io> wrote:

> Java mixes the ability to catch catastrophic errors with programming
> errors; that’s part of the problem. Swift’s approach is that the throws
> construct is for *recoverable* errors.
>
> I’m perfectly fine with allowing:
>
> func foo() throws -> () {}
>
> And
>
> func foo() throws MyError -> () {}
>
> The proposal states that.
>
> What the typed version allows is the ability specifically validate that
> all of the error constructs (assuming an enum ErrorType) have been handled.
> If you still want to use the “catch-all”, that’s fine, you can do so. I’m
> not proposing to take away your ability to throw any ErrorType conforming
> type you want to.
>
> -David
>
> On Dec 7, 2015, at 4:06 PM, Andrew Bennett via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Isn't it better to have the choice of type safety, and perhaps have a
> compiler option or linter to enforce it (if you choose).
>
> Default syntax:
> func foo() throws; // defaults to ErrorType
>
> Optional type safety:
> func foo() throws(MyError); // note, only one type.
>
> When it comes down to it, for me, the problem is that you can catch
> anything you like, and the check for exhaustivity does not check what may
> actually be thrown, resulting in excess code and compile-time errors.
>
>
> On Tue, Dec 8, 2015 at 9:24 AM, Russ Bishop via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> IMHO be careful what you wish for. If the compiler enforces this then
>> we're just repeating the mistakes of Java's checked exceptions. All roads
>> would eventually lead to "throws ErrorType", defeating the supposed purpose.
>>
>> russ
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> _______________________________________________
> 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/20151208/440774da/attachment.html>


More information about the swift-evolution mailing list