Issue #21282 has been updated by sanjioh (Fabio Sangiovanni). On a second thought, I've come to the conclusion that the benefits in clarity that a fix would provide are not worth the associated performance impact (i.e. the additional search for the real class required to format the error message). This issue can be closed (sorry for the noise). ---------------------------------------- Bug #21282: `FrozenError` raised by `rb_error_frozen_object` should mention real class of frozen object https://bugs.ruby-lang.org/issues/21282#change-112782 * Author: sanjioh (Fabio Sangiovanni) * Status: Open * ruby -v: ruby 3.5.0dev (2025-04-23T14:19:58Z fix-frozenerror-me.. 5c9dd42e27) +PRISM [x86_64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Hello everyone, I've noticed that the following snippets both raise `FrozenError`, but with different messages: ``` ruby Object.new.freeze.instance_variable_set(:@test, true) # can't modify frozen Object: #<Object:0x000000010b4d8aa8> (FrozenError) ``` ``` ruby Object.new.freeze.tap(&:singleton_class).instance_variable_set(:@test, true) # can't modify frozen #<Class:#<Object:0x0000000101538a98>>: #<Object:0x0000000101538a98> (FrozenError) ``` As you can see, the second example mentions the singleton class of the object, while I would expect `Object` to be mentioned in its place, as the first example does. From what I can see in `test/ruby/test_frozen_error.rb`, the expected behavior here should be to display the real class of the frozen object (as returned by `Kernel#class`), independently of the existence of a singleton class. I'm working on a PR that should fix this (will post the link in the comments in a moment). Cheers! -- https://bugs.ruby-lang.org/