> On Feb 27, 2017, at 4:19 AM, Daniel Leping via swift-evolution > <[email protected]> wrote: > > > On Mon, 27 Feb 2017 at 8:44 Dave Abrahams via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > > on Fri Feb 17 2017, Joe Groff <[email protected] > <mailto:[email protected]>> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
