in reply to Re^3: Printing an object when you only have the refaddr string for it
in thread [SOLVED] Printing an object when you only have the refaddr string for it

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.
  • Comment on Re^4: Printing an object when you only have the refaddr string for it
  • Download Code

Replies are listed 'Best First'.
Re^5: Printing an object when you only have the refaddr string for it
by AnomalousMonk (Archbishop) on Nov 05, 2015 at 21:27 UTC

    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:  <%-{-{-{-<

      Haha yeah so that's just it. The trick is that the data structure is massive and I don't know exactly what it's complaining about every time because the array it's pointing to is 15 arrays deep with multiple objects at that same level. and so there would be multiple objects there containing a "color" value, but I don't know which one because all I have is the refaddr to identify it.
      LOOKING FOR ARRAY(0x7fa9bc68be78) . . . | | | | | | | | | | | | | | | |- 3 [ +A220] ARRAY(0x7fa9bc68be78)

      The work around is to iterate over each individual one and keep track of the item name as "curName" for example, but it's a lot of code cluttering the subroutines doing actual work and not something I can just segregate into the sub that handles error output in my application.