[swift-evolution] Proposal: Typed throws

[Russ Bishop]

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).

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.

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.
 

russ

> On Dec 7, 2015, at 4:28 PM, David Owens II <david at owensd.io> wrote:
> 
> 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 recoverable errors. 
> 
> I’m perfectly fine with allowing:
> 
> func foo() throws -> () {}
> 
> And
> 
> func foo() throws MyError -> () {}
> 
> The proposal states that.
> 
> 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.
> 
> -David
> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151207/dc60919f/attachment.html>