When Swift Makes You Use “throws” Instead of “rethrows”
rethrowslets you specify that a function can only throw if one of the functions passed to it as a parameter can throw. It enforces this by only allowingtryto be applied to calls to those functions orrethrowsfunctions which are being passed those functions, and only allowingthrowsinside acatchblock.However, this enforcement can sometimes get in the way. For example, this function only throws if the function it is passed throws, but the compiler cannot statically prove this to itself[…]
[…]
It is possible to work around this by exploiting certain bugs in the
rethrowschecking—theDispatchoverlay does this to add error handling toDispatchQueue.sync(execute:)—but this is not ideal for obvious reasons.
Via Ole Begemann:
We can use the same trick for our problem. Check out the relevant code in the Swift repository. And here’s the verbatim copy of the code (I only changed the function names) for
performAndWait[…][…]
performAndWaitnow calls through to a private helper function that takes two throwing functions (the original block and an error handler) and this convinces the compiler that therethrowsinvariant holds.
1 Comment RSS · Twitter
[…] in many more places than before. It’s still not allowed as a parameter type, though. I have a case where I want to ensure that a method has a parameter of the receiver’s own type. I […]
