[Pitch N+1] Typed Throws

Lily_Ballard · October 3, 2023, 6:10am

Oh gosh, this was a long time ago. In the PR discussion you'll see I shared an example of a rethrows function modifying the error being thrown

github.com/apple/swift

Comment by lilyball to [Sema] Allow catch blocks to rethrow errors when safe

apple:master ← lilyball:better_rethrows_analysis

@jrose-apple I actually disagree about the typed errors; the `catch` block would… have to only throw errors that are part of the declared set of types, but I see no reason why it can't return a different error, such as one that wraps the error thrown by the parameter. Furthermore, I don't think we can reasonably define "the function will never throw its _own_ errors" without being needlessly restrictive. For example, my own code that motivated this change looks like ``` swift func scoped<T>(key: String, @noescape f: () throws -> T) rethrows -> T { do { return try f() } catch let error as JsonError { throw error.withPrefix(key) } } ``` (where `JsonError.withPrefix()` returns a new error that has the given key prefixed onto the access path) This function is not throwing its own error, it's merely modifying the error that was thrown, but I don't see how to define "throw its _own_ errors" in any meaningful fashion that doesn't prevent this usage.

This example actually comes from code in my PMJSON framework which did exactly this:

github.com

postmates/PMJSON/blob/1221cbdf2573bbd693e6ecd2da3f012dec9ff1d8/Sources/JSONError.swift#L1799-L1805


      
          internal func scoped<T>(_ key: String, _ f: () throws -> T) rethrows -> T {
              do {
                  return try f()
              } catch let error as JSONError {
                  throw error.withPrefix(.key(key))
              }
          }

In fact, this code is the original motivation for the change.

(warning: if you look at the code history of that repo you'll find my deadname)