<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="">In the context of error handling, a "sub-enum" (a term I might use again to describe enum-backed enums) is an easy and scalable way to tailor the error reporting interface of a function. If David Owens II's&nbsp;<a href="https://github.com/owensd/swift-evolution/blob/master/proposals/allow-type-annotations-on-throw.md" class="">annotated throws proposal</a>&nbsp;goes in, you can make an enum that has just the errors that your function can raise and you don't need to bother catching the rest.</div><div class=""><br class=""></div><div class="">Without it, taking your example, if I have a function that can throw NetworkException.NoInternetError, the annotation will still be NetworkException and you'll need a catch clause for SecurityError (or a catch-all) to be exhaustive. If you add a new NetworkException value, you need to update every call site to catch that value (or, again, use a catch-all). A sub-enum tailored to the function would increase resilience to changes in the underlying enum.</div><div class=""><br class=""></div><div class="">Maybe that tailored enum could even be synthesized by the compiler. That would be very cool for internal/private interfaces. (I'm not sure how the enum resilience thing Chris talks about will play out, so I wouldn't suggest that for public interfaces yet.)</div><div class=""><br class=""></div><div class="">Félix<br class="">
<br class=""><div><blockquote type="cite" class=""><div class="">Le 18 déc. 2015 à 14:21:35, Sean Heber via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class="">This worked for me:<br class=""><br class="">enum NetworkException: ErrorType {<br class=""> &nbsp;&nbsp;&nbsp;case NoInternetError, SecurityError<br class="">}<br class=""><br class="">enum ParseException: ErrorType {<br class=""> &nbsp;&nbsp;&nbsp;case FailedResponse(statusCode: Int)<br class=""> &nbsp;&nbsp;&nbsp;case EmptyResponse<br class=""> &nbsp;&nbsp;&nbsp;case MissingField(fieldName: String)<br class="">}<br class=""><br class="">enum ChangePictureError: ErrorType {<br class=""> &nbsp;&nbsp;&nbsp;case Network(NetworkException)<br class=""> &nbsp;&nbsp;&nbsp;case Parse(ParseException)<br class="">}<br class=""><br class="">func thing() throws {<br class=""> &nbsp;&nbsp;&nbsp;throw ChangePictureError.Parse(.FailedResponse(statusCode: 401))<br class="">}<br class=""><br class="">func thing2() {<br class=""> &nbsp;&nbsp;&nbsp;do {<br class=""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;try thing()<br class=""> &nbsp;&nbsp;&nbsp;} catch ChangePictureError.Parse(.FailedResponse(statusCode: 401)) {<br class=""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;print("401")<br class=""> &nbsp;&nbsp;&nbsp;} catch {<br class=""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;print("some other error")<br class=""> &nbsp;&nbsp;&nbsp;}<br class="">}<br class=""><br class="">I must admit that I’ve generally avoided exceptions (aka using Java) throughout my entire programming career thus far and so don’t have extensive experience with this sort of situation. :)<br class=""><br class="">l8r<br class="">Sean<br class=""></div></div></blockquote></div><br class=""></div></body></html>