[swift-evolution] Proposal: Typed throws

[David Waite]

My $0.02:

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

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?

- Documenting the specific errors that a method may throw is useful.
- 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)
- 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.

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.

-DW

> On Dec 7, 2015, at 5:06 PM, Andrew Bennett via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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).
> 
> Default syntax:
> func foo() throws; // defaults to ErrorType
> 
> Optional type safety:
> func foo() throws(MyError); // note, only one type.
> 
> 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.
> 
> 
> On Tue, Dec 8, 2015 at 9:24 AM, Russ Bishop via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 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.
> 
> russ
>  
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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