[swift-evolution] [Pitch] Typed throws

[Joe Groff]

> On Feb 27, 2017, at 4:19 AM, Daniel Leping via swift-evolution <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.

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170227/a19cbe7b/attachment.html>