on Mon Feb 27 2017, Daniel Leping <daniel-AT-crossroadlabs.xyz> wrote:
> Well, as Dave pointed, you can very rarely recover from an error, which IMO > is absolutely true. > > If your operation fails you don't really care unless you can recover. And > you know your cases, which you can recover from (in reality one usually > does it in optimization phase, though). > > What else do you need the type of error for at the very end of your call > stack? In 90% you will tell the user "ah, sorry, something happened. Come > back later" and log the error (if you haven't forgot it). > > In most cases the errors are not for recovering. They neither are to be > presented to users. They are for developers to read the log/crash > report/whatever else and analyze it. Most of the errors are for debugging > purposes. Disagreed, sorry. When I said that recovery is rare, I meant that it is generally done in a very few functions, not that it is rarely possible at all. If something goes wrong when editing a document, for example full or network failure, you simply recover its previous state from the undo stack. Errors are *for* recoverable conditions. If you're not going to recover you might as well trap and save all the unwinding and invariant preservation logic. > I don't want to deal with cumbersome code the purpose of which is to just > "obey the language rules". Unless I know how to recover I would rethrow it. > Than catch at the top of the stack and log + show the user a nice "sorry" > message without getting techy. > > On Tue, 28 Feb 2017 at 1:12 Matthew Johnson via swift-evolution < > [email protected]> wrote: > >> >> > On Feb 27, 2017, at 5:01 PM, Dave Abrahams <[email protected]> wrote: >> > >> > >> > on Mon Feb 27 2017, Matthew Johnson <matthew-AT-anandabits.com> wrote: >> > >> >>> On Feb 27, 2017, at 4:20 PM, Dave Abrahams <[email protected]> >> wrote: >> >>> >> >>> >> >>> I'm sorry, I don't see any substantive difference, based on what you've >> >>> written here, between this feature and const. >> >> >> >> Let me give it one more shot and then I’ll drop it. :) >> >> >> >> Const is viral because if an API does not declare its arguments const >> >> it cannot be used by a caller who has a const argument. >> > >> > Unless the caller casts away const, thus erasing information that was >> > previously encoded in the type system. >> >> Yes, of course. >> >> > >> >> It is required in order to make an API as generally useful as >> >> possible. >> >> >> >> Typed errors are not viral in this way because no callers are >> >> prevented from calling an API regardless of whether it declares error >> >> types or just throws Error like we have today. >> > >> > Unless the caller can recover (which is *very* rare) or it catches and >> > rethrows one of the errors *it* declares, thus erasing information that >> > was previously encoded in the type system. >> >> I view this as being fundamentally different than casting away const. >> Casting away const says “I know better than the types”. >> >> Converting an error to a different type is extremely different. It much >> more similar to any other kind of value wrapper a library might create in >> order to shield its users from being coupled to its implementation details >> / dependencies. This is not a way *around* the type system in the sense >> that casting away const is. It is a way of *using* the type system >> (hopefully) to your advantage. >> >> >> >> > >> >> Pressure to declare error types in your signature in order to make >> >> your function as generally useful as possible does not exist. Each >> >> function is free to declare error types or not according to the >> >> contract it wishes to expose. >> >> >> >> An argument can be made that community expectations might develop that >> >> good APIs should declare error types and they could be considered >> >> viral in this sense because any API that is simply declared `throws` >> >> is dropping type information. But I think this overstates the case. >> >> The community appears to be very sensitive to the problems that can >> >> arise when error types are too concrete, especially across module >> >> boundaries. I think we can learn to use the tool where it works well >> >> and to avoid it where it causes problems. >> >> >> >>> >> >>> -- >> >>> -Dave >> >> >> > >> > -- >> > -Dave >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> -- -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
