> There's no reason we couldn't do some tooling work to expose emergent
> information about what kinds of errors are thrown by the current
> implementation of a function, and maybe even check that against the current
> documentation. Certainly, it should be possible to document particularly
> interesting errors that a function might throw.
I'd prefer moving some complicated and controversial questions out of the
language level, and probably, this might be such a case — but I think the
preferred syntax would not be "throws(NetworkError, MyError) func mayFail()
throws", but rather something that looks much more integrated ("func mayFail()
throws(NetworkError, MyError)")
> I'm just challenging the idea that this should be reflected and enforced in
> the type system.
Yes, I think this might be a can of worms — just imagine rethrows, where some
errors will always be caught, so that ultimately, we would steer towards some
kind of type algebra just for errors...
>> Typed throws could also help to lessen the tight coupling to Objective-C:
>> Being forced to declare conformance to a protocol without requirements or
>> even public methods feels very awkward to me.
>
> Error is not about Objective-C interop; we could make the feature work
> without a protocol, and in fact the protocol alone isn't sufficient for what
> we try to do with it. The protocol's value is mostly communicative, a way of
> making it obvious that a type is meant to be thrown
I guess nearly all uses look like "XYError: Error", so I really don't see much
value in the protocol; but to me, it always feels a little bit dirty when
language features are entwined with certain types, so it might be just a
personal oddity.
>> If people want to build huge lists of possible errors… why not? As long as
>> I'm still able to write my own throwing functions as today, I'm fine with
>> that.
>
> Language features have to meet a higher bar than "why not?".
That was more geared towards something I'd consider as derailed use — but it
seems we agree that typed throws don't have to be something to bother the
compiler with.
- Tino
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
