... I will only ever need to access it immediately while it's still in scope ...
The phrase "... it will error out with a message ..." in the OP suggests that an exception has already been thrown, suggesting in turn that the scope of the object has been exited and the object itself marked for garbage collection. Does the thrown exception carry a copy of the object reference, thereby defeating GC, in addition to a mere stringization thereof? That seems to me to be the only hope you would have of reliably going back to the object in question with the object of dumping it in some useful way.
Give a man a fish: <%-{-{-{-<
| [reply] [d/l] |
That is correct, there is an array reference it carries with the object. nested under $obj-{error}->[ arrayref here with more array refs under it ]
while the function $obj->error provides the stringification at $obj->{error}->{message}
Verified it's still in scope using Data::TreeDumper which shows the address.
| [reply] [d/l] |
But if you have a fresh, live, wriggling copy of the object reference in your hand, where's the problem? Why go to any trouble trying to convert a stringized address back into a live pointer/reference? Just drill down into the nested object reference to the point at which the problem appears (Ok, this might be a bit tricky, but even so...) and then Data::Dumper it from there on down.
Give a man a fish: <%-{-{-{-<
| [reply] [d/l] |
For your universal version, you need to run the program in an environment that has access to the module's symbol table. It would not surprise me to find out such a thing exists; it's far beyond what I know :)
2 minutes with Super Search comes up with Devel::SymDump.
| [reply] |