> On Aug 18, 2017, at 6:29 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Fri, Aug 18, 2017 at 6:19 PM, Matthew Johnson <matt...@anandabits.com > <mailto:matt...@anandabits.com>> wrote: > >> On Aug 18, 2017, at 6:15 PM, Xiaodi Wu <xiaodi...@gmail.com >> <mailto:xiaodi...@gmail.com>> wrote: >> >> On Fri, Aug 18, 2017 at 09:20 Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >> Sent from my iPad >> >> On Aug 18, 2017, at 1:27 AM, John McCall <rjmcc...@apple.com >> <mailto:rjmcc...@apple.com>> wrote: >> >> >> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution >> >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Splitting this off into its own thread: >> >> >> >>> On Aug 17, 2017, at 7:39 PM, Matthew Johnson <matt...@anandabits.com >> >>> <mailto:matt...@anandabits.com>> wrote: >> >>> One related topic that isn’t discussed is type errors. Many third party >> >>> libraries use a Result type with typed errors. Moving to an async / >> >>> await model without also introducing typed errors into Swift would >> >>> require giving up something that is highly valued by many Swift >> >>> developers. Maybe Swift 5 is the right time to tackle typed errors as >> >>> well. I would be happy to help with design and drafting a proposal but >> >>> would need collaborators on the implementation side. >> >> >> >> Typed throws is something we need to settle one way or the other, and I >> >> agree it would be nice to do that in the Swift 5 cycle. >> >> >> >> For the purposes of this sub-discussion, I think there are three kinds of >> >> code to think about: >> >> 1) large scale API like Cocoa which evolve (adding significant >> >> functionality) over the course of many years and can’t break clients. >> >> 2) the public API of shared swiftpm packages, whose lifecycle may rise >> >> and fall - being obsoleted and replaced by better packages if they >> >> encounter a design problem. >> >> 3) internal APIs and applications, which are easy to change because the >> >> implementations and clients of the APIs are owned by the same people. >> >> >> >> These each have different sorts of concerns, and we hope that something >> >> can start out as #3 but work its way up the stack gracefully. >> >> >> >> Here is where I think things stand on it: >> >> - There is consensus that untyped throws is the right thing for a large >> >> scale API like Cocoa. NSError is effectively proven here. Even if typed >> >> throws is introduced, Apple is unlikely to adopt it in their APIs for >> >> this reason. >> >> - There is consensus that untyped throws is the right default for people >> >> to reach for for public package (#2). >> >> - There is consensus that Java and other systems that encourage lists of >> >> throws error types lead to problematic APIs for a variety of reasons. >> >> - There is disagreement about whether internal APIs (#3) should use it. >> >> It seems perfect to be able to write exhaustive catches in this >> >> situation, since everything in knowable. OTOH, this could encourage abuse >> >> of error handling in cases where you really should return an enum instead >> >> of using throws. >> >> - Some people are concerned that introducing typed throws would cause >> >> people to reach for it instead of using untyped throws for public package >> >> APIs. >> > >> > Even for non-public code. The only practical merit of typed throws I have >> > ever seen someone demonstrate is that it would let them use contextual >> > lookup in a throw or catch. People always say "I'll be able to >> > exhaustively switch over my errors", and then I ask them to show me where >> > they want to do that, and they show me something that just logs the error, >> > which of course does not require typed throws. Every. Single. Time. >> >> I agree that exhaustive switching over errors is something that people are >> extremely likely to actually want to do. I also think it's a bit of a red >> herring. The value of typed errors is *not* in exhaustive switching. It is >> in categorization and verified documentation. >> >> Here is a concrete example that applies to almost every app. When you make >> a network request there are many things that could go wrong to which you may >> want to respond differently: >> * There might be no network available. You might recover by updating the UI >> to indicate that and start monitoring for a reachability change. >> * There might have been a server error that should eventually be resolved >> (500). You might update the UI and provide the user the ability to retry. >> * There might have been an unrecoverable server error (404). You will >> update the UI. >> * There might have been a low level parsing error (bad JSON, etc). Recovery >> is perhaps similar in nature to #2, but the problem is less likely to be >> resolved quickly so you may not provide a retry option. You might also want >> to do something to notify your dev team that the server is returning JSON >> that can't be parsed. >> * There might have been a higher-level parsing error (converting JSON to >> model types). This might be treated the same as bad JSON. On the other >> hand, depending on the specifics of the app, you might take an alternate >> path that only parses the most essential model data in hopes that the >> problem was somewhere else and this parse will succeed. >> >> All of this can obviously be accomplished with untyped errors. That said, >> using types to categorize errors would significantly improve the clarity of >> such code. More importantly, I believe that by categorizing errors in ways >> that are most relevant to a specific domain a library (perhaps internal to >> an app) can encourage developers to think carefully about how to respond. >> >> I used to be rather in favor of adding typed errors, thinking that it can >> only benefit and seemed reasonable. However, given the very interesting >> discussion here, I'm inclined to think that what you articulate above is >> actually a very good argument _against_ adding typed errors. >> >> If I may simplify, the gist of the argument advanced by Tino, Charlie, and >> you is that the primary goal is documentation, and that documentation in the >> form of prose is insufficient because it can be unreliable. Therefore, you >> want a way for the compiler to enforce said documentation. (The >> categorization use case, I think, is well addressed by the protocol-based >> design discussed already in this thread.) > > Actually documentation is only one of the goals I have and it is the least > important. Please see my subsequent reply to John where I articulate the > four primary goals I have for improved error handling, whether it be typed > errors or some other mechanism. I am curious to see what you think of the > goals, as well as what mechanism might best address those goals. > > Your other three goals have to do with what you term categorization, unless I > misunderstand. Are those not adequately addressed by Joe Groff's > protocol-based design?
Can you elaborate on what you mean by Joe Gross’s protocol-based design? I certainly haven’t seen anything that I believe addresses those goals well. > >> >> However, the compiler itself cannot reward, only punish in the form of >> errors or warnings; if exhaustive switching is a red herring and the payoff >> for typed errors is correct documentation, the effectiveness of this kind of >> compiler enforcement must be directly proportional to the degree of >> extrinsic punishment inflicted by the compiler (since the intrinsic reward >> of correct documentation is the same whether it's spelled using doc comments >> or the type system). This seems like a heavy-handed way to enforce >> documentation of only one specific aspect of a throwing function; moreover, >> if this use case were to be sufficiently compelling, then it's certainly a >> better argument for SourceKit (or some other builtin tool) to automatically >> generate information on all errors thrown than for the compiler to require >> that users declare it themselves--even if opt-in. >> >> >> Bad error handling is pervasive. The fact that everyone shows you code that >> just logs the error is a prime example of this. It should be considered a >> symptom of a problem, not an acceptable status quo to be maintained. We >> need all the tools at our disposal to encourage better thinking about and >> handling of errors. Most importantly, I think we need a middle ground >> between completely untyped errors and an exhaustive list of every possible >> error that might happen. I believe a well designed mechanism for >> categorizing errors in a compiler-verified way can do exactly this. >> >> In many respects, there are similarities to this in the design of `NSError` >> which provides categorization via the error domain. This categorization is >> a bit more broad than I think is useful in many cases, but it is the best >> example I'm aware of. >> >> The primary difference between error domains and the kind of categorization >> I am proposing is that error domains categorize based on the source of an >> error whereas I am proposing categorization driven by likely recovery >> strategies. Recovery is obviously application dependent, but I think the >> example above demonstrates that there are some useful generalizations that >> can be made (especially in an app-specific library), even if they don't >> apply everywhere. >> >> > Sometimes we then go on to have a conversation about wrapping errors in >> > other error types, and that can be interesting, but now we're talking >> > about adding a big, messy feature just to get "safety" guarantees for a >> > fairly minor need. >> >> I think you're right that wrapping errors is tightly related to an effective >> use of typed errors. You can do a reasonable job without language support >> (as has been discussed on the list in the past). On the other hand, if >> we're going to introduce typed errors we should do it in a way that >> *encourages* effective use of them. My opinion is that encouraging effect >> use means categorizing (wrapping) errors without requiring any additional >> syntax beyond the simple `try` used by untyped errors. In practice, this >> means we should not need to catch and rethrow an error if all we want to do >> is categorize it. Rust provides good prior art in this area. >> >> > >> > Programmers often have an instinct to obsess over error taxonomies that is >> > very rarely directed at solving any real problem; it is just self-imposed >> > busy-work. >> >> I agree that obsessing over intricate taxonomies is counter-productive and >> should be discouraged. On the other hand, I hope the example I provided >> above can help to focus the discussion on a practical use of types to >> categorize errors in a way that helps guide *thinking* and therefore >> improves error handling in practice. >> >> > >> >> - Some people think that while it might be useful in some narrow cases, >> >> the utility isn’t high enough to justify making the language more complex >> >> (complexity that would intrude on the APIs of result types, futures, etc) >> >> >> >> I’m sure there are other points in the discussion that I’m forgetting. >> >> >> >> One thing that I’m personally very concerned about is in the systems >> >> programming domain. Systems code is sort of the classic example of code >> >> that is low-level enough and finely specified enough that there are lots >> >> of knowable things, including the failure modes. >> > >> > Here we are using "systems" to mean "embedded systems and kernels". And >> > frankly even a kernel is a large enough system that they don't want to >> > exhaustively switch over failures; they just want the static guarantees >> > that go along with a constrained error type. >> > >> >> Beyond expressivity though, our current model involves boxing thrown >> >> values into an Error existential, something that forces an implicit >> >> memory allocation when the value is large. Unless this is fixed, I’m >> >> very concerned that we’ll end up with a situation where certain kinds of >> >> systems code (i.e., that which cares about real time guarantees) will not >> >> be able to use error handling at all. >> >> >> >> JohnMC has some ideas on how to change code generation for ‘throws’ to >> >> avoid this problem, but I don’t understand his ideas enough to know if >> >> they are practical and likely to happen or not. >> > >> > Essentially, you give Error a tagged-pointer representation to allow >> > payload-less errors on non-generic error types to be allocated globally, >> > and then you can (1) tell people to not throw errors that require >> > allocation if it's vital to avoid allocation (just like we would tell them >> > today not to construct classes or indirect enum cases) and (2) allow a >> > special global payload-less error to be substituted if error allocation >> > fails. >> > >> > Of course, we could also say that systems code is required to use a >> > typed-throws feature that we add down the line for their purposes. Or >> > just tell them to not use payloads. Or force them to constrain their >> > error types to fit within some given size. (Note that obsessive error >> > taxonomies tend to end up with a bunch of indirect enum cases anyway, >> > because they get recursive, so the allocation problem is very real >> > whatever we do.) >> > >> > John. >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
