Refine handling of CanThrow capabilities #13866
Conversation
Restrict catch patterns to `ex: T` with no guard under saferExceptions so that capabilities can be generated safely. Fixes scala#13849
| checkedArgs = checkedArgs.mapconserve(arg => | ||
| checkSimpleKinded(checkNoWildcard(arg))) | ||
| else if tycon == defn.throwsAlias | ||
| && checkedArgs.length == 2 | ||
| && checkedArgs(1).tpe.derivesFrom(defn.RuntimeExceptionClass) |
There was a problem hiding this comment.
Is there really a gain in explicitly preventing users from declaring throwing RuntimeExceptions? And even if we disallow methods like
def foo(): Int throws ArithmeticException = ???then
def foo()(using CanThrow[ArithmeticException]): Int = ???will be still valid, right? So this somehow defeats the purpose IMHO
There was a problem hiding this comment.
We won't generate a capability for it, so it's better to communicate that early. But I think ding this for throws clauses is enough. I don't want to start imposing restrictions on general implicit parameters.
| | ^ | ||
| | The capability to throw exception ArithmeticException is missing. | ||
| | The capability can be provided by one of the following: | ||
| | - A using clause `(using CanThrow[ArithmeticException])` |
There was a problem hiding this comment.
If we don't synthesize instances of CanThrow for subtypes of RuntimeException then this message is rather misleading than helpful, as propagating this capability with using clauses won't make the compilation succeed unless someone creates such an instance by themself. And X throws ArithmeticException won't even compile
|
That's an @implicitiNotFound error message, and IMO it should stay one. There is no way we can customize the message according to what the caught exception is. |
|
Then at least maybe we could extend the generic |
Fixes #13864
Fixes #13846
Fixes #13849