Issue #22007 has been updated by headius (Charles Nutter). byroot (Jean Boussier) wrote in #note-8:
I suspect removing that limitation wouldn't prevent JITs from optimizing the overwhelming majority of `rescue` statements as they'd still only list one of a few classes.
Well, it wouldn't be any worse than it is now, but optimizing execution handling is not high on my priority list. If the rescue clause only has constants, you can guard on those constants staying the same, and whether they use the standard `Class#===` implementation and maybe not intercept objects that are not `is_a?`. People shouldn't be relying on exceptions to be fast in any case though, because just generating a backtrace is an enormous amount of work. ---------------------------------------- Bug #22007: Inconsistent type checking on rescue https://bugs.ruby-lang.org/issues/22007#change-117078 * Author: zenspider (Ryan Davis) * Status: Open * ruby -v: 4.0.2 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- this works fine (but I don't think it should): ```ruby begin raise "nope" rescue RuntimeError, /why am I allowed?/, "or me?" => e # yay end ``` whereas this version shows a type error, which seems right: ```ruby begin begin raise "nope" rescue /why am I NOT allowed/, "if I was allowed before?" => e p e end rescue TypeError => te p te end ``` I think all the args on rescue should be checked to be `Module` -- https://bugs.ruby-lang.org/