Let me add to this since I mostly agree. I personally distinguish between 3 types of diagnostics: (1) The user level errors koolade describes above; (2) errors given to prgrammers using a given published API; and (3) full programmer level diagnostics.
I'd agree with koolade's approach, but that only covers the first and third cases. For an applications programmer using some interface I developed, I want to give them that middle ground: Tell them which line of their program is in error but not lead them into a bunch of code they're never supposed to see. So that's where I've used things like $CarpLevel (even though it can be a pain in the arse).
As an example, I wrote a generalized interface for setting up class and instance level attributes. Part of that checks against allowed values, etc. If a programmer calls a method with invalid arguments I simply want to say something like Option FOO is not recognized at line 120 of yourprogram. That's different than a user giving me a bad command line argument, where I'd simply say something like Option -foo is not recognized.. I would not want to show the user in that first message a stack trace though. My experience, like jeffa's is that it just confuses things and they start thinking things are broken that aren't. I would show a stack trace for exceptions that were unexpected; e.g., errors in my underlying code versus errors in usage of that code.
In reply to Re: Re: Confusion about properly using Carp
by steves
in thread Confusion about properly using Carp
by jeffa
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |