[swift-evolution] Proposal: Typed throws

[Austin Zheng]

My personal use case for typed throws would have been as a replacement
(within the context of an interpreter for a different language) for:

func doSomething() -> Result<T, MyInterpreterRuntimeError> {
  guard someCondition() else {
    return .Failure(MyInterpreterRuntimeError(...))
  }
  guard anotherCondition() else {
    return .Failure(MyInterpreterRuntimeError(...))
  }
  // ...
  return .Success(T(...))
}

becomes...

func doSomething() (throws MyInterpreterRuntimeError) -> T {
  guard someCondition() else {
    throw MyInterpreterRuntimeError(...)
  }
  guard anotherCondition() else {
    throw MyInterpreterRuntimeError(...)
  }
  // ...
  return T(...
}

The more I think about this use case, though, the more I feel like I'm
misusing the mechanism for syntax sugar, as John alluded to earlier. If
this isn't a compelling argument for some sort of typed throws support,
though, I would at least like to see better support for a stdlib Result
type, although there are pitfalls there as well and that's a topic better
elaborated upon within a different thread.

Austin

On Mon, Dec 7, 2015 at 4:51 PM, David Waite via swift-evolution <
swift-evolution at swift.org> wrote:

> 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> 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
>> 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
>
>
>
> _______________________________________________
> 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/407d40ea/attachment.html>