[swift-evolution] [Pitch] Typed throws

[Matthew Johnson]

> On Feb 27, 2017, at 3:34 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Feb 27, 2017, at 4:19 AM, Daniel Leping via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>> On Mon, 27 Feb 2017 at 8:44 Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> on Fri Feb 17 2017, Joe Groff <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> > Experience in other languages like Rust and Haskell that use
>> > Result-based error propagation suggests that a single error type is
>> > adequate, and beneficial in many ways.
>> 
>> 
>> And experience in still others, like C++ and Java, suggests that
>> using static types to restrict the kind of information a function can
>> give you when an error occurs may actually be harmful.
>> +1 here. It becomes wrapping over wrapping over wrapping. Try doing a big app in Java (i.e. some kind of layered server) and you'll understand everything. Ones who tried and still want it - well, there are different tastes out there.
> 
> OTOH, people *don't* seem to have these problems with Rust and functional languages with value-oriented error handling. This could be partly because there's a greater focus on fully-closed systems in those communities where resilience isn't a concern, and you can usually evolve all your use sites if you need to break an API, whereas C++ and Java projects are more likely to incorporate black-box components from multiple sources. Having affordances for unwinding with a well-typed error *within* a component seems like a generally useful thing; Haskell has do notation and Rust tosses macros at the problem to hide the propagation boilerplate, after all.

+1.  There are places where typed errors are very useful and places where they can cause problems (as with many features a programming language can have).

> 
> -Joe
> _______________________________________________
> 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/20170227/337af493/attachment.html>