[swift-evolution] Type-annotated throws

[Kevin Nattinger]

+1 from me.  I’m usually highly defensive about types, so the more the compiler can guarantee the better. 

> On Aug 26, 2016, at 9:01 AM, Nur Ismail via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi,
> 
> Sounds like checked exceptions of Java with a similar syntax. With Java you have to specify the exceptions a method can throw. However been lots of debate over the years whether it's a good thing or bad thing, some like it, but I think many more hate it.

I’m pretty sure what people don’t like in Java is the enforced error handling or propagation and how much you have to nest to, e.g. set up IO, though I believe that has been mitigated somewhat by try-with-resources), not the specificity (and how it’s not obvious to many which throws need to be caught at compile time and which are RuntimeExceptions).  Though I don’t write much Java nowadays, I know I never liked all the boilerplate that required.

> Most other languages don't have it, and possibly for good reason.

I’d love to hear those arguments against letting the compiler make more guarantees.

> 
> Regards,
> 
> On Fri, Aug 26, 2016 at 5:43 PM, Rod Brown via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> (resent for Swift Evolution)
> 
> I’m a big fan of this idea. Currently “throws” seems like a very limited API - you know it’s throwing out something, but you can only hope to guess what that is or create fallbacks. Definitely a big +1 from me. A fallback for compatibility could be “throws” assumes “throws Any” and can be a warning?

I’d suggest a bare `throws` = `throws ErrorType` (you can only throw ErrorType, right?) and be valid, I don’t see any reason to make it a warning (plus that keeps source compatibility). 

> 
> While I am not deeply familiar with the implications, I do like think your line of reasoning has merit, and think this makes sense for Phase 1 of Swift 4. 
> 
> - Rod
> 
> 
>> On 27 Aug 2016, at 1:39 AM, Félix Cloutier via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Hi all,
>> 
>> Currently, a function that throws is assumed to throw anything. There was a proposal draft last December to restrict that. The general idea was that you'd write, for instance:
>> 
>>> enum Foo: ErrorProtocol {
>>>     case bar
>>>     case baz
>>> }
>>> 
>>> func frob() throws Foo {
>>>     throw Foo.bar // throw .bar?
>>> }
>> 
>> If you `catch Foo` (or every case of Foo), now that the compiler can verify that your catch is exhaustive, you no longer have to have a catch-all block at the end of the sequence.
>> 
>> This impacts the metadata format and has implications on resilience, which leads me to believe that the discussion could qualify for the phase 1 of Swift 4. If this is the case, I'd be interested in pulling out the old discussions and seeing where we left that at.
>> 
>> Félix
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/20160826/8132ac7c/attachment.html>