Issue #22007 has been updated by headius (Charles Nutter). I think the better fix would be to reject literal types that are clearly not going to match. Ideally, the only cases that should be admitted to a rescue would be constant accesses, or other expressions that could potentially resolve a type. That cuts out a huge range of literals we can prove will never match an exception. ...unless the goal is to allow rescue to match anything anywhere anytime, in which case every rescue clause must evaluate every expression and make a dynamic method call even when there's practically no chance of it matching. Personally, I would prefer if the arguments to rescue were either a constant or an opaque expression. 99% of cases will be the constant and we can much more easily optimize for that case. ---------------------------------------- Bug #22007: Inconsistent type checking on rescue https://bugs.ruby-lang.org/issues/22007#change-117068 * 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/