develooper Front page | perl.perl5.porters | Postings from March 2021

try/catch visibility to caller()

Thread Next
Paul "LeoNerd" Evans
March 7, 2021 15:44
try/catch visibility to caller()
Message ID:
There's an odd quirk about eval {} blocks, in that they are visible to
caller(), and hence turn up in the stack traces thrown by
Carp::longmess and friends:

  $ perl
  use Carp;
  sub C { Carp::cluck("Boo") }
  sub B { eval { C() } } 
  sub A { eval { B() } }
  Boo at - line 2.
          main::C() called at - line 3
          eval {...} called at - line 3
          main::B() called at - line 4
          eval {...} called at - line 4
          main::A() called at - line 5

That is sortof understandable if you consider that caller() is supposed
to tell us about successive levels of the "caller stack", where
"return" would send us.

But how caller() works internally is that it looks down the context
stack - which in addition to sub calls and eval {} frames, also
contains information about foreach loops and other fun things. Those
are invisible to caller().

A quirk of its current (experimental) implementation means that
try/catch blocks are also invisible to caller():

  $ bleadperl
  use experimental 'try';
  use Carp;
  sub C { Carp::cluck("Boo") }
  sub B { try { C() } catch($e) {} }
  sub A { try { B() } catch($e) {} }
  Boo at - line 3.
          main::C() called at - line 4
          main::B() called at - line 5
          main::A() called at - line 6

I think this is a useful property for them to have.

However, I didn't document or unit-test for it [1]. I'd like to propose
adding tests and documentation of that to ensure this property remains.

Do we agree?

(Cross-posted to github:

[1]: Actually until I wrote that example just now, I thought they
     *would* be visible so this mail was going to propose changing it.

Paul "LeoNerd" Evans      |  |

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About