http://www.perlmonks.org?node_id=1065565


in reply to Re^5: How/can one do save/restore CORE::caller inside an eval?
in thread How/can one do save/restore CORE::caller inside an eval?

CORE::caller is always the built in caller function and can't be changed. CORE::GLOBAL::caller can be changed, and if it exists will be used by a caller() call instead of CORE::caller. Note that the function to use is chosen at compile time.

This is why the BEGIN block is needed in other cases of overriding caller. Perl picks which of the functions to use for a given caller() call when compiling the code. Once it has chosen to use CORE::GLOBAL::caller, the implementation for that function can be switched out and it will use whatever is currently stored in it. In your case, caller() calls directly in evaled code will always be compiled after you set up your override. Anyone using caller indirectly, such as through Carp, would be dealing with already compiled code and it would ignore your override.

Another potential issue is that CORE::caller() has special cased behavior for when called from the DB package. Your code will cause all caller calls to be from the DB package, which means @DB::args will always be populated even when that wasn't the intent. While that doesn't break any obvious things, it is a change in semantics. The effect of this is also currently limited by the previously mentioned compilation issue.

Properly maintaining the semantics of the original function takes extra care. I would recommend looking at Sub::Uplevel. You can likely use it directly to do the frame skipping, fixing both of the above issues. If not, its code can provide guidance on what you need to do.

  • Comment on Re^6: How/can one to save/restore CORE::caller inside an eval?

Replies are listed 'Best First'.
Re^7: How/can one do save/restore CORE::caller inside an eval?
by rockyb (Scribe) on Dec 04, 2013 at 12:24 UTC

    Thanks for the information!

    Anyone using caller indirectly, such as through Carp, would be dealing with already compiled code and it would ignore your override.

    Given the choice of the slowness of a global override and having someone in the debugger evaluate a Carp and get results that will probably show up in the debugger (since Carp with one level is the most common case), I'll opt for the faster different eval results. If I come accross a specific case where I am annoyed by this, I'll reassess then

    Another potential issue is that CORE::caller() has special cased behavior for when called from the DB package. Your code will cause all caller calls to be from the DB package, which means @DB::args will always be populated even when that wasn't the intent. While that doesn't break any obvious things, it is a change in semantics. The effect of this is also currently limited by the previously mentioned compilation issue.

    Properly maintaining the semantics of the original function takes extra care. I would recommend looking at Sub::Uplevel. You can likely use it directly to do the frame skipping, fixing both of the above issues. If not, its code can provide guidance on what you need to do.

    I don't immediately see how this changes things in my case.

    I looked at Sub::Uplevel. The environment and faking going on in my DB code is sufficiently complex that I don't want to introduce more stuff, and other routines adding additional fakery, unless I understand why specifically it is needed. I rely on the tests I have written and when those are insufficient, bug reports and my own experience to tell me if I think things are okay.