<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="">Both Java and C# have uncatchable (or un-stoppable) exceptions for various catastrophic errors and in fact Java’s checked exceptions are a lie partially for that reason. C# doesn’t have checked exceptions but go ahead and try to catch StackOverflowException or ThreadAbortException (the former will die immediately, the latter will pretend to be caught then get re-thrown).</div><div class=""><br class=""></div><div class="">As a library author all this does is promote wrapping errors with useless wrappers. If I touch the filesystem, I am subject to any number of filesystem errors. If I touch the network I am subject to any number of network errors. What is gained by wrapping those? If the OS is updated and the system API throws a new type of error does that mean my library is broken? If not, then the supposed contract is a lie. If my library calls another library, I’ve multiplied the boilerplate to handle that error (now the user needs to catch OtherLibraryErrorType and MyLibraryErrorType where e.innerError is OtherLibraryErrorType). Even if you solved the fragile interface problem there’s still pressure to perform the wrapping (and pressure on library authors not to introduce new error types) because I upgraded the library and now all my catch clauses are incomplete, potentially causing massive breakage due to a minor change in some core library function that ripples outward.</div><div class=""><br class=""></div><div class="">I understand the desire to avoid having the general catch-all but IMHO in most cases that is a mistake in design. If you aren’t prepared to handle any possible error and you aren’t rethrowing/throwing or retrying on all errors then you’re probably catching errors in the wrong place and should just pass them up the chain to someone else who can take action based on the error. Almost all error handling responses boil down to some combination of a) log it, b) try again later, or c) give up and die.</div><div class=""> </div><div class=""><br class=""></div><div class="">russ</div><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 7, 2015, at 4:28 PM, David Owens II <<a href="mailto:david@owensd.io" class="">david@owensd.io</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Java mixes the ability to catch catastrophic errors with programming errors; that’s part of the problem. Swift’s approach is that the throws construct is for <i class="">recoverable</i> errors. </div><div class=""><br class=""></div><div class="">I’m perfectly fine with allowing:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">func foo() throws -> () {}</font></div><div class=""><br class=""></div><div class="">And</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">func foo() throws MyError -> () {}</font></div><div class=""><br class=""></div><div class="">The proposal states that.</div><div class=""><br class=""></div><div class="">What the typed version allows is the ability specifically validate that all of the error constructs (assuming an enum ErrorType) have been handled. If you still want to use the “catch-all”, that’s fine, you can do so. I’m not proposing to take away your ability to throw any ErrorType conforming type you want to.</div><div class=""><br class=""></div><div class="">-David</div><br class=""><div class=""><blockquote type="cite" class=""><div class=""><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>