<div dir="ltr">My personal use case for typed throws would have been as a replacement (within the context of an interpreter for a different language) for:<div><br></div><div>func doSomething() -> Result<T, MyInterpreterRuntimeError> {</div><div> guard someCondition() else {</div><div> return .Failure(MyInterpreterRuntimeError(...))</div><div> }</div><div> guard anotherCondition() else {</div><div> return .Failure(MyInterpreterRuntimeError(...))</div><div> }</div><div> // ...</div><div> return .Success(T(...))</div><div>}</div><div><br></div><div>becomes...</div><div><br></div><div>func doSomething() (throws MyInterpreterRuntimeError) -> T {</div><div> guard someCondition() else {</div><div> throw MyInterpreterRuntimeError(...)</div><div> }</div><div> guard anotherCondition() else {</div><div> throw MyInterpreterRuntimeError(...)</div><div> }</div><div> // ...</div><div> return T(...</div><div>}</div><div><br></div><div>The more I think about this use case, though, the more I feel like I'm misusing the mechanism for syntax sugar, as John alluded to earlier. If this isn't a compelling argument for some sort of typed throws support, though, I would at least like to see better support for a stdlib Result type, although there are pitfalls there as well and that's a topic better elaborated upon within a different thread.</div><div><br></div><div>Austin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 7, 2015 at 4:51 PM, David Waite via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>My $0.02:</div><div><br></div><div>When the errors thrown by a protocol are constrained to just MyError, what are your options for reporting other types of errors that your implementation can generate (such as a database error, IO error, and so on). </div><div><br></div><div>Is wrapping one of those in a MyError really that useful? Does that mean a MyError enumeration is going to contain an .Other(ErrorType) case to deal with them? Why not (in that case) just have the calling code catch said other exceptions and deal with them generically?</div><div><br></div><div>- Documenting the specific errors that a method may throw is useful.</div><div>- Indicating for some functions that *only* those specific types can be thrown is useful, and may warrant compiler support (enforcement of said declaration, allowing exhaustive catches)</div><div>- Documenting that you may also get exceptions dependent on objects or closures that you have supplied is also useful. Rethrows implicitly does a little of this today.</div><div><br></div><div>I however point to Java as an example that exhaustive checked exceptions are a bad idea (and in Java, they aren’t even exhaustive - RuntimeException and Error types and subtypes are unchecked). The use of Errors as a signaling mechanism for alternate flows should be kept to a minimum.</div><div><br></div><div>-DW</div><div><div class="h5"><div><br></div><div><div><div><div><blockquote type="cite"><div>On Dec 7, 2015, at 5:06 PM, Andrew Bennett via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div dir="ltr">Isn't it better to have the choice of type safety, and perhaps have a compiler option or linter to enforce it (if you choose).<div><br></div><div>Default syntax:</div><div>func foo() throws; // defaults to ErrorType</div><div><br></div><div>Optional type safety:</div><div>func foo() throws(MyError); // note, only one type.</div><div><br></div><div>When it comes down to it, for me, the problem is that you can catch anything you like, and the check for exhaustivity does not check what may actually be thrown, resulting in excess code and compile-time errors.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 8, 2015 at 9:24 AM, Russ Bishop via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">IMHO be careful what you wish for. If the compiler enforces this then we're just repeating the mistakes of Java's checked exceptions. All roads would eventually lead to "throws ErrorType", defeating the supposed purpose.</div><div class="gmail_quote"><br></div><div class="gmail_quote">russ</div></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=pQw7h83fWt3LLbgkfL4TSUL0weaZnVFZxDe5GShw4uShB06FGTXMSkgj0zcILepLN1SxfsyIFi84rt4dtPuPvmM-2Btr7bI15-2BUywQZfodHtR1ohtCDOEg7qxC-2F2URXwCOJpzFO8qCwqBi7Hxtt4lkHT5nNgsmuDg8f-2Bzj4dAQQDWxROdOWAKLetq9NUQ-2F-2BEjbFuSIIvD9MqrlCbDDwCeSrvu1z24Vf6lK2cnRPQzoP-2FY-3D" alt="" width="1" height="1" border="0" style="min-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">
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=nE9rxSXA5G4kxsTVkgv43vFcOQoCM-2FU-2BigXPSqPoICJXumJOEIq4OlsK4wJY6csPMsh1eebtMoP8iSZc-2BanGaVs2y805aW4NdecLeZQBRZtOkss1MwJ7BCYrDTRLv7M2zSLXbiS-2B5NKNuAzQ-2BxTBx168UH1nfiGhdCjWLgXLfn2fGBd-2FHnCgoeMo3NrFq0teSQOPg9XLwXJZmTqakJ-2F-2Ff2fhbOFxlyX07pHozs8SHZI-3D" alt="" width="1" height="1" border="0" style="min-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">
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=7XtDdMHRjqIUi4tzSjSp2pWQIyxYdP6woIWn4vwV5gft0ClTCUf2blzBAbr3g9fePgrvUXtZRuH10JDtNAQrl92DyRToaB2Lfbm7bvQL5Nx4nxy5r8AzqgcK6Cyx3eODHBG-2BWPpUtjnnhuq4rDu3E4npGVqIy5TAzx3uOGfxStLirgfeUs1Ez4JlXFsTUywabr1u-2BpSwlNqHbGCZWNwttY8I8a1GomgfPjaqSwz-2FkHg-3D" alt="" width="1" height="1" border="0" style="min-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">
</div></div></div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>