<head></head><body><div>Hi all,</div><div><br></div>I am very much pro this addition, if for nothing else than more information for the developer using the API.<div><div><br></div><div><div>Limiting `throws MyErrorType` to only Enums, Structs and final Classes gets around the Java problems so far as I can see.</div><div><br></div><div>As for the usefulness of this, I'm working on a fairly large project, and the only way of documenting what errors can be thrown is through documentation comments, which must then be maintained — there is little worse than incorrect/out-of-date documentation. Although currently the catch-all is mandated, guaranteeing safety, as a developer I'm equally concerned about recovering from an error: without knowing exactly which Enum can be thrown, or what subset of cases can occur, I either have to navigate to the source code and go down the rabbit hole of tracking that information down, or just accepting that I don't know what'll be thrown (and thereby potentially not recovering from a recoverable failure). </div><div><br></div><div>I find it really frustrating that the compiler is unable to help me out with this, even though in certain cases I _can_ guarantee what will be thrown. If this proposal also brings about more convenient pattern matching for error handling, that's a +2 from me.</div><div><br></div><div><br<br style="line-height: 1.4;">—</br<br></div><br<br><div>Alex Popov Jr.</div><div>Principal iOS Developer | Shelfie</div></br<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Dec 18 2015, at 9:42 am, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
<br>
<meta content="text/html charset=utf-8"><br><div><blockquote type="cite"><div>On Dec 18, 2015, at 10:50 AM, David Owens II <<a href="mailto:david@owensd.io">david@owensd.io</a>> wrote:</div><br><div><br><blockquote type="cite">On Dec 18, 2015, at 5:53 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>> wrote:<br><br>David,<br><br>Thank you for taking the time to continue working on a proposal for typed throws. I agree that this feature is very desirable and appreciate the work you’re doing to bring forward a proposal. I think it’s a great start but also has some room for improvement.<br><br>First, I think it could be strengthened by incorporating some learning from Rust. My impression is that the Rust community is very happy with typed error handling. Adding some detail about their experience would provide a counter-example to those who are concerned about the experience in Java and C++.<br></blockquote><br>I’m not involved in the Rust community so I wouldn’t feel comfortable making claims for them. <br></div></blockquote><div><br></div><div>I’m not asking for you to speak for them. But I do think we need to learn from communities that are having success with typed error handling. Your proposal would be stronger if it went into detail about how it would avoid the problems that have been encountered in other languages. The experience of Rust could help to make that case as it is concrete and not hypothetical.</div><br><blockquote type="cite"><div><br><blockquote type="cite">I agree that error types are an important part of an API contract. One of the big hurdles to doing this well is the need to catch errors when all that needs to be done is to wrap and rethrow them. Ideally should not need to do this just to perform a simple type translation to map the underlying error into the type we wish to expose as part of a stable API contract. You might want to take a look at the From mechanism Rust uses to facilitate this. IMO a proposal for typed error handling should address this issue in some way (even if the author determines this mechanism is not necessary or a good design cannot be identified).<br></blockquote><br>The From() construct seems like a map(T) -> U problem, but it seems heavily tied into the ability to create sum types. Swift doesn’t have this feature, and that feature is out-of-scope for this proposal. More on this later.<br></div></blockquote><div><br></div><div>My understanding is that Rust uses static multi-dispatch to do this. I don’t believe it has anything to do with structural sum types. Rust error handling uses a Result type with a single error case: <a href="http://doc.rust-lang.org/book/error-handling.html">http://doc.rust-lang.org/book/error-handling.html</a>.</div><div><br></div><div>If you don’t believe a mechanism like this is necessary and don’t include one in your design it will lead to either a lot of boilerplate or avoidance of typed errors (depending on the developer). I think you should expect a lot of complaints about this and I think it will generate a lot of -1 votes for the proposal.</div><br><blockquote type="cite"><div><br><blockquote type="cite">I would also like to see much more detail on why you think allowing a function to throw multiple error types is problematic. My impression is that you have concerns from a usability point of view. I am on the fence here to some degree, but definitely leaning in the direction that allowing a function to throw multiple error types is better. <br></blockquote><br>Sure. There’s no functionality today to auto-generate a sum type in Swift today, and that is what this request really is. If you want to return multiple return types, then you need to do exactly what Rust does and create a sum type that composes the various types of errors. This exposes the same potential fragile API surface as extending enums do. I did call this part out specifically.</div></blockquote><div><br></div>How does this create a fragile API surface area? Adding a new error type to the signature would be a breaking change to the API contract. This is really no different than changing the type of error that can be thrown under your proposal.</div><div><br><blockquote type="cite"><div>I see this functionality as a general limitation in the language. For example, errors are not the only context where you may want to return a type of A, B, or C. There have been other proposals on how we might do that in Swift. If and when it was solved in the general case for type parameters, I can’t foresee a compelling reason why it wouldn’t work in this context as well.<br></div></blockquote><div><br></div><div>That makes sense in some ways, but I don’t think it’s unreasonable to ask for some analysis of whether a better design for typed errors would be possible if we had them. IMO it’s pretty important to get the design of typed errors right if / when we add them. If we don’t it will be considered a major mistake and will lead to a lot of less than desirable outcomes down the road.</div><div><br></div><div>I also think typed errors may be one of the more important use cases for structural sum types of some kind. If we are able to show that design problems that <b>cannot</b> be solved without them <b>can</b> be solved with them that might influence whether they are added or not. It might also influence <b>when</b> it makes sense to add support for typed errors to the language.</div><div><br></div><blockquote type="cite"><div><br><blockquote type="cite">I am willing to be convinced that a single error type is better than multiple error types but the current proposal does not provide a compelling argument in that direction. It just says “Java checked exceptions”. I know these have been pretty much universally considered a serious design mistake. My impression is that there are quite a few reasons for that. I don’t have any direct experience with Java and am not familiar with the details. If you could elaborate on specifically why you believe allowing multiple error types was a significant contributor to the problem in a manner that indicates that they will be a problem in any language that includes them I would appreciate that. Links would be sufficient if they are focused on answering this particular question. <br></blockquote><br>I guess I should have just specifically called this out in the proposal. It’s not because of “Java checked exceptions”, it’s because nowhere else in the language are types allowed to be essentially annotated in a sum-like fashion. We can’t directly say a function returns an Int or a String. We can’t say a parameter can take an Int or a Double. Similarly, I propose we can’t say a function can return an error A or B.<br><br>Thus, the primary reason is about type-system consistency.<br><br>Swift already supports a construct to create sum types: associated enums. What it doesn’t allow is the ability to create them in a syntactic shorthand. In this way, my error proposal does the same thing as Rust: multiple return types need to be combined into a single-type - enum.</div></blockquote><br></div><div>That approach would make catch clauses rather clunky by nesting errors inside of associated values. If you’re advocating for this approach do you have any ideas on how to streamline syntax for catching them?</div><div><br></div><div>Matthew</div><div><br></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=CmwAv3oRa0AH4Hd1bWC6X-2BzbhPqo1YEo6mPHEujr90vUljsud-2BB6KUDP5cz-2Fv0xXzcKh2I7l3AVBGsasABqpSVQZA47MBrZnIRbuczKfFabYpw7SI-2FEE3vWg8ZsRzYrusFrkP3-2Fdfov48EZIMr1UIxRUjZjSkWFw5gJSpy8pL-2Fo1jlRzHx1-2B7tEBTDx1EdAI9LfCCL-2FD4vOGJSJXCTPis0shiFWB5ZEKHAD1LQ3af20-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;">
</blockquote></body>