> The only practical merit of typed throws I have ever seen someone demonstrate
> is that it would let them use contextual lookup in a throw or catch. People
> always say "I'll be able to exhaustively switch over my errors", and then I
> ask them to show me where they want to do that, and they show me something
> that just logs the error, which of course does not require typed throws.
> Every. Single. Time.
I think the aspect of documentation shouldn't be underestimated:
People want to know what might go wrong — even if they have only a single
reaction to all cases at their disposal.
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.
In some way, throws are typed already, but there's just one type allowed, and
it can't be changed.
Imho the big problem of the whole topic is the bad experience people had with
typed throws in Java; I don't see a problem in adding typed throws and keeping
Error as default type to be thrown if nothing else is specified.
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.
- Tino
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
