|Welcome to the Monastery|
unified warnings, good or bad?by leocharre (Priest)
|on Nov 25, 2009 at 19:18 UTC||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.
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..
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?