<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">My $0.02:</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">- Documenting the specific errors that a method may throw is useful.</div><div class="">- 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 class="">- 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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">-DW</div><div class=""><br class=""></div><div class=""><div class=""><div class=""><div><blockquote type="cite" class=""><div class="">On Dec 7, 2015, at 5:06 PM, Andrew Bennett via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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 class=""><br class=""></div><div class="">Default syntax:</div><div class="">func foo() throws; // defaults to ErrorType</div><div class=""><br class=""></div><div class="">Optional type safety:</div><div class="">func foo() throws(MyError); // note, only one type.</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Dec 8, 2015 at 9:24 AM, Russ Bishop via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><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 class=""></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" class="">
<br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></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="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;" class="">
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></div></body></html>