Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

unified warnings, good or bad?

by leocharre (Priest)
on Nov 25, 2009 at 19:18 UTC ( #809406=perlmeditation: print w/ replies, xml ) Need Help??

I use a mix of tools for debugging and warnings.

I use warn(), die()- and they're good. They don't tell you much though. Using Carp you get a lot more info.

In cases where I have code that might be getting used from far down the calling stack, and it will issue a warning, I have found Carp::cluck() to be of great use. Carp::carp() would *seem* like a good choice replacement for warn() in these cases, but it's thrown me off- If you don't write your message well- it can be a little confusing to tell where the warning happened.
At least, I for one have been confused by it.

Carp::cluck() I've found a wonderful replacement for both warn() and Carp::carp(). Carp::cluck() shows you the calling stack as Carp::confess() will- but does not exit. It's a warning, and it looks as scary as throwing a Carp::confess() exception.

Carp::cluck() is very nice for these places where you issue a warning in code that might be called from far away. What may turn some people off to using it, is the verbosity.

Another thing I use a lot is Smart::Comments- this is very useful for tests, for seeing what's up when are in development. For production, Smart::Comments is pretty poor, I think the author mentions this as well. One of the reasons important to me here, is that the output is pretty much a print statement. You're not gonna automatically get a stack trace or any such info- it's just what you write. So in a situation where the call stack might be levels deep,- good luck knowing where '### 5' came from. Great for development, not for production.

I also went ahead and wrote my own debug(), so that it would show me what sub did what where, and I could enable and disable the messages via $MyModule::DEBUG, this has its use here and there. I've found that useful in production- when many interdependencies are doing something I don't understand- I turn debug flags on and sometimes that shows me what's up.

Lately I've had one unifying fantasy to sort of do away with all of the various methods of debugging and warning. I'm thinking of only using warn(), and die() in all of my code.

And having some module (just to standardize)- to make all warn() to behave as Carp::cluck(), or as debug(), or to shut up- and all die() for Carp::confess() or..
This would obviously be done with signal trapping.
There are examples of this out there, such as Carp::Always.

Imagine that.. All code with warn() and die(). Triggered at runtime to behave as debug(), as stack backtrace... or to shut up completely- all via $MyModule::ERROR_SETTINGS flags and such. Does this sound like beauty and simplicity- or.. Is there something I am missing. Maybe there would be something horrible in that- Something I'm not noticing?

It would mean that all your code would have warn() and die()- and depending on runtime settings, they would behave as debug (turn off message), or as Carp, showing you much detail- etc. You could develop and you'd set the level to be max- thus using Carp::cluck or such into warnings- and maybe when the code is being used in production it will resume being simply warn()- Who knows. Thing is- you won't be able to look at the code and know for certain how warn and die outputs- they may even be silenced by a caller to your package/code- that's what I'm wondering about- is there some inherent evil I am failing to notice here?

Comment on unified warnings, good or bad?
Re: unified warnings, good or bad?
by toolic (Chancellor) on Nov 25, 2009 at 21:30 UTC
    There are some times when I wish I could temporarily demote all my die and croak's while I'm debugging. For example, when I'm parsing a file which has bad data in it, my code will give me an error message, then it will exit. So, I fix the bad data, re-run, then get another error message. This could go on for many iterations. Sometimes it's useful to know as many errors as possible at once. The only way I know of to do this is to edit my code and replace all die with warn. That's a lot of fun.

    Also, I have developed the habit of using Carp carp instead of cluck because I can easily promote the latter to the former by Forcing a Stack Trace from the command line using

    perl -mCarp=verbose
      Try *CORE::GLOBAL::die = \&do_something_else.
Re: unified warnings, good or bad?
by Jenda (Abbot) on Nov 26, 2009 at 13:24 UTC

    There's one important difference between warn vs. carp and die vs. croak. The later is "from perspective of caller". Loosing the distinction would be fairly bad.

    If your subroutine complains about an invalid/missing parameter, it's pointless to tell the developer the position of the test, you want him to know the position of the call so you carp/croak. OTOH, if something goes crazy within the inner workings of the subroutine, it should warn/die.

    You can turn croak() to confess() and carp() to cluck() by "use Carp qw(verbose);" or by "perl -MCarp=verbose script.pl" and it would be nice to be able to control warn() and die() like this as well, but definitely not by turning them to confess() and cluck(). You'd loose the first (several) frame(s)!

    Jenda
    Enoch was right!
    Enjoy the last years of Rome.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (11)
As of 2014-09-19 12:51 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (138 votes), past polls