| [#1168] | project: compiler | priority: low | category: bug | |
|---|---|---|---|---|
| submitter | assigned to | status | date submitted | |
| Iulian | Martin | fixed | 2007-06-05 10:16:42.0 | |
| subject | [contrib #649] matching code for thrown exceptions broken | |||
| code |
object ExceptionHandlingTest extends Application {
trait SpecialException {}
try {
throw new Exception
} catch {
case e : SpecialException => {
println("matched SpecialException")
assume(e.isInstanceOf[SpecialException])
}
case e : Exception => {
assume(e.isInstanceOf[Exception])
}
}
} |
|||
| what happened | matching on a thrown exception behaves differently than regular matching. |
|||
| what expected | no assumptions should fail. matching success | |||
| [back to overview] | ||||
| Iulian edited on 2007-06-05 10:17:13.0 |
| Iulian edited on 2007-06-05 11:35:21.0 |
| I simplified the example. I have the feeling it's the new unapply patterns at the root of this bug, but I'm not sure. Here's what I know: - the first typed pattern (e: SpecialException) does not conform to the prototype (java.lang.Throwable). Instead of failing, the type checker changes it to (e: Throwable with SpecialException). - Erasure makes 'e' just a Throwable, and adds the appropriate casts in the body. Since this happens after patternmatching, the additional check for SpecialException is missing. - the backend adds an exception handler for Throwable, which catches everything. The spec says that the patterns in a try-catch must conform to Throwable, and does not say anything about the silent addition of Throwable. But I guess the original poster's intuition, that pattern matching and exception matching should agree, is the right one. |
| Martin edited on 2007-07-02 18:24:39.0 |
| The example now compiles and runs OK. |