I know what you mean about stack traces being big, noisy, pointless things -- and I totally agree. But it may be that the uses I've seen and had for carp/croak haven't been so "deep" that their output has been a problem for me.
On the contrary, I've been really grateful for all the times where a given method or function from a module is being used in a lot of different places in an app that I'm working on, and when I make a mistake, carp or croak tells me which line number in calling code triggered it -- without a whole lot of other useless trivia (all the args passed at every layer of the call stack, what their memory addresses were, what the command-line looks like as hex bytes, blah blah blah...)
(My colleagues who use python don't seem care much about error reports -- every time one of their python scripts hits a dead-end, the user gets several lines of doggerel with seemingly random white-space/line-breaks and rarely a legible word, let alone a coherent phrase. Even for cases where the user just needs to be told "file foobar not found". I don't understand why anyone would want or allow errors to be handled in such a way. But I generally don't see this sort of thing with perl code using carp or croak.)
If you feel that users of your module are very unlikely to call a given method or function from more than one spot in their apps, don't worry about it. But if it's likely that one app might use a given sub in lots of different places, you'll probably be doing the module user a very big favor by telling which line in the caller's code caused a given problem.
In reply to Re: Replacing warn/die with carp/croak?
by graff
in thread Replacing warn/die with carp/croak?
by dragonchild
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |