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.