Re^2: blessed confusion

Slightly more convenient for me is to have the call-back dumped for warnings as well as errors and to make it conditional on the prog's development status. So the following is already in this prog (as it's in my 'new program template'...

my $Devel=1;
...
if ($Devel) {
    use Carp qw(cluck confess);
    $SIG{__WARN__} = $SIG{__DIE__} = 
        sub { 
            &dumpfromstart; 
            $Carp::CarpLevel=1;
            confess @_
        }
}
[download]

The 'dumpfromstart' is specific to this program, as it uses Data::Dumper to try to dump out data from the starting object and the current if it is different and non-null.

For me, it's easier if every program starts with initializations like above than having to type invocations on the command line when there are problems.

Comment on Re^2: blessed confusion Download Code

Replies are listed 'Best First'.
Re^3: blessed confusion by ikegami (Patriarch) on Sep 09, 2010 at 05:10 UTC
Carp::Always does extend warnings. `>perl -MCarp::Always -we"sub f { print undef } f()" Use of uninitialized value in print at -e line 1 main::f() called at -e line 1` [download] It's also conditional (on a command line option), which is surely better than changing the source code to do debugging. Either way, you didn't report back any findings. Did you solve your problem?	[reply] [d/l]
Re^4: blessed confusion by perl-diddler (Chaplain) on Sep 09, 2010 at 21:35 UTC
<quote> conditional (on a command line option), which is surely better... </quote> Not for me. I want it on all the time during development (a phase in which something may stay for the life of the program!). So having to type in anything extra on a command line just once wouldn't be worth it. The command may be in my path, but may not be in the current directory -- so I'd also have to use the -S switch if I ran it using 'perl xxx'. Problem was addressed by first response -- the error message can be interpreted ambiguously and talks about the "errors" effect on a particular model rather than what the error is. So I was looking at the 'blessed' statement's target rather than what was being used to bless the target -- problem was that the RH operand of the bless wasn't a "value", due to the stack being confused. The error message was trying to interpret the effect of what was going on, saying: 'error: you are trying to bless into a <insert random type from stack>', where random value was a hash. Once I knew it was complaining about the RH of the bless and not the LH, the error was obvious: the constructor was called as PKG::new instead of PKG->new. I figured it had to be something basic I was missing (like never having seen that particular error before, and misinterpreting it), cuz, I really thought I had at least a passing understanding of the objects -- and that led to the 'lame mistake' of me using the wrong calling convention. The rest of the suggestions were things that were pretty much already covered in my code, in some perlish fashion (different but equal...:-) ). Thanks much for all the suggestions!	[reply]
Re^5: blessed confusion by ikegami (Patriarch) on Sep 09, 2010 at 23:14 UTC
If you want it in the code instead of as an option, you can use `use Carp::Always;`.	[reply] [d/l]