And I doubt that PadWalker can cause instabilities just by parsing the optree!
No? Try
perl -MPadWalker=peek_my
-e"my $x = 42; sub { my $closed_over = $x; sub { peek_my 0 } }->()->()
+"
In any way I wouldn't suggest using code filters for error msgs in productive code...
Neither did I.
But then neither would I recommend the tracing of variables in production code.
The need for that is: a) a clear sign of inadequate testing; b) poor design.
Excepting Acts of God and Cosmic Rays, given the same values, code produces the same results. The only source of variability is IO.
And if this is a permanent feature of your logging or error handling, then the trivial extra investment to log:
20100327204831.321 file.pl(87): Received '...' from socket:0xdeadbeef
over
20100327204831.321 file.pl(87): $buf = '...';
The point is that noone, neither programmer nor user, is going to be able to draw any conclusions from "$buf = '...', without consulting the source. And with the file and line number, the variable that contains the value is obvious. Making it unnecessary information in the log.
For development time debugging, watching the values of variables change without reference to the source can give the programmer clues to his mistakes--out by one being the classic. And Smart::Comments is ideal for this.
But once you move into production, there is always a better identification for a value--more meaningful to both user and maintenance programmer alike--than the internal variable identifier.
You won't agree. And I won't argue the point further.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
|