Issue #6372 has been updated by mame (Yusuke Endoh). Status changed from Feedback to Assigned Target version changed from 1.9.3 to 2.0.0 Because you didn't explain use case at all, I didn't understand the spec of your code nor what you really want. You are talking about tests, right? Yes, the current design of exception class hierarchy is too coarse for tests. The fact does not applies only to throw. The following examples do all raise an ArgumentError, but their meanings vary very much. def foo(x); end; foo(1, 2) #=> wrong number of arguments (2 for 1) (ArgumentError) 1.step(10, 0) { } #=> step can't be 0 (ArgumentError) a = []; a << a; a.flatten #=> tried to flatten recursive array (ArgumentError) A general policy for exception class design is required, I think. Indeed we can define a specific sub exception class for each, but the task may be expensive. And, it may make new feature proposal slightly difficult: "the feature is good, the method name is also good, but the name of exception class for its corner case is not good, so we need more discussion..." -- Yusuke Endoh <mame / tsg.ne.jp> ---------------------------------------- Feature #6372: More specific error for uncaught throw https://bugs.ruby-lang.org/issues/6372#change-26288 Author: trans (Thomas Sawyer) Status: Assigned Priority: Normal Assignee: matz (Yukihiro Matsumoto) Category: core Target version: 2.0.0 I have this method: =begin class Symbol # Does the block throw the symbol? # def thrown? catch(self) do begin yield true rescue ArgumentError => err # 1.9 exception false rescue NameError => err # 1.8 exception false end end end end =end But it was recently pointed out to me that the rescue of ArgumentError and NameError is not good enough b/c they might rescue an unrelated error of the same type. So to make this right there needs to be a more specific error. Perhaps `class ThrowError < ArgumentError`. -- http://bugs.ruby-lang.org/