Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

On the dangers of too much debugging text

by redlemon (Hermit)
on Mar 28, 2008 at 13:39 UTC ( #676982=perlmeditation: print w/ replies, xml ) Need Help??

I'm using Catalyst to build an application, and are using the Catalyst::Controller::BindLex module to keep the code more readeable:

my $value :Stashed = 1;

in stead of

$c->stash( value => 1 );

This is all great stuff until you have:

sub action : Chained('other_action') { my $value: Stashed; # # a bit of code using $value # my $value: Stashed = 1; }

The last line was there in the initial iteration of the action, the first line got added after some redesign.

Catalyst server started up as usual with a summary of actions, paths, plugins, and a lot of my own debug prints. The first notice something was wrong was when I got:

panic: Can't find SCALAR(0x3240d90) in the the caller's lexical pa +d

This sent me on a merry chase through all the internals using the debugger. Somehow BindLex saw a different address for $value than the one I saw in the debugger. After a couple of hours, lots of coffee, and some silly experiments I decided to take a shower and go to bed. It was after 5AM after all....

Somewhere between shower and bed it dawned on me. The reason BindLex was seeing a different address must be because there were 2 vars with the same name in the subroutine's scope!! So I went back and looked closely at the output of the server start again, and there it was, as the first line of output:

"my" variable $value masks earlier declaration in same scope.

So, lessons learned:

  • There's such a thing as too much debugging output
  • There is some really clever magic going on in BindLex, Devel::Caller and PadWalker. Kudo's for the people who came up with that code.
  • There is a point where focussing too much on a problem becomes counter-productive. Stop and go do something else and enlightenment follows.

--
Lyon

Comment on On the dangers of too much debugging text
Select or Download Code
Re: On the dangers of too much debugging text
by zby (Vicar) on Mar 28, 2008 at 14:17 UTC
    Or one can also conclude that BindLex is evil. I mean - that was clearly your error - but if were not using BindLex you would have found it much faster.
Re: On the dangers of too much debugging text
by perrin (Chancellor) on Mar 28, 2008 at 14:40 UTC
    my $value :Stashed = 1; in stead of $c->stash( value => 1 );
    Wow. Never in a million years would I have guessed those two lines were meant to do the same thing. I'm not seeing how this makes anything more readable.
Re: On the dangers of too much debugging text
by kyle (Abbot) on Mar 28, 2008 at 16:27 UTC

    I think of "my $value :Stashed = 1;" as being more like...

    my $value = $c->stash->{value} = 1;

    ...except that $value remains an alias for $c->stash->{value} afterward.

Re: On the dangers of too much debugging text
by dragonchild (Archbishop) on Mar 28, 2008 at 16:54 UTC
    I'm with perrin on this one. Having used BindLex on a project before, I think it makes using globals waaaay too easy. The problem is that the stash (and flash) are global variable repositories. They're useful, otherwise mst would've killed nothingmuch before he could've finished adding it. But, they're useful in the way that a Doberman is useful. You just don't let the Doberman have the run of the place. Stashed variables should be very obviously stashed variables. The easiest way to do this is to have the stashed variable be accessible only through the long function call. The point behind a lexical is that it's safe - whatever you throw into it won't leave the current scope. BindLex violates that guarantee.

    I think this falls under the "rope enough to hang yourself with" part of Perl. But, I'm also crochety. Meh.


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Re: On the dangers of too much debugging text
by oko1 (Deacon) on Mar 28, 2008 at 19:51 UTC
    > So I went back and looked closely at the output of the server start again, and
    there it was, as the first line of output:
    

    One of the earliest lessons I learned about Perl - and that I teach to my students these days - is "always look at the first reported error. Often, solving that one takes care of all or many of the subsequent ones."

    
    -- 
    Human history becomes more and more a race between education and catastrophe. -- HG Wells
    

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://676982]
Approved by Arunbear
Front-paged by Erez
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (15)
As of 2014-08-01 16:49 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Who would be the most fun to work for?















    Results (32 votes), past polls