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