TSPL Pitch: Typed throws

Swift Documentation
5

Hi @Alex_Martini,

I am providing this feedback as someone who is only familiar with the gist of typed throws from a high level.

First, overall, I found the outline clear and just reading the outline I feel I have a much better understanding of typed throws.

  1. I strongly agree with @tcldr that it is important to emphasize that most code does not need to use typed throws, and possibly spell out why using untyped throws is preferred.

  2. In the list of reasons why you would use typed throws, it wasn't clear to me why this would be one of those cases:

    • In code that only rethrows errors, especially when the throwing code comes from a closure the caller provided. Example: map in the stdlib. Xref to reference section -- this chapter doesn't discuss rethrows

  3. In the discussion of "You can also use opaque types like throws(some MyErrorProtocol)", possibly clarify that you can't dynamically return different types of MyErrorProtocol at runtime. (Although I realize that is more of an opaque type topic than a typed throws topic.)

  4. For me, the biggest unexpected syntax was seeing throws as part of do syntax:

    do throws(SomeErrorType) { ... }

    I was definitely expecting some change to throws in function declarations.

    Maybe some language that mentioned how Swift has always used do statements in cases where you want to catch thrown errors in your own code, and that now with typed throws, declaring a do block has been expanded to include this new syntax.

    (And I am guessing that you can't write do throws { untyped errors, the throws is implied.)

  5. Elsewhere in TSPL it is stated that ' Every switch statement must be exhaustive .' and that includes switch statements that include a default case.

I think following that conceptual model, untyped throws can be handled exhaustively, if a general catch / default is provided, but it is only required by typed throws.

Definitely looking forward to the first fleshed-out draft!

1 Like