[swift-evolution] Type-annotated throws

[Haravikk]

I like checked exceptions in Java so I'd be in support of this, as I feel it's a helpful feature to ensure that exceptions are properly handled.

I never really understood the complaints against it, as you're still free to just use a generic catch block for "everything else", and we have things like try? and try! when you don't expect an exception and just want to keep things simple, so the situation is already easier than in Java.

I'd say that there should still be generic "could throw anything" variant, like throws ErrorProtocol or such, but in most cases a well-defined error type (or several types?) is best, as developers should really think about what types of errors they produce and how someone might handle them when designing a method, and users of the method should be thinking about how they can recover from an error if it occurs, or fail in a more graceful/informative manner if they can't. Currently I don't think Swift's untyped throws achieve that.

> On 26 Aug 2016, at 17:01, 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.
> Most other languages don't have it, and possibly for good reason.
> 
> 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?
> 
> 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/437977d0/attachment.html>