Re: Confusion about properly using Carp

Now, philosophical question: if this really should be desired behavior and left alone, then i am all for that.

Carp may not really be what you need here. If your error messages are intended to be seen by programmers (i.e., you when you're debugging) then you should leave the entire trace so you (or a maintainer) don't go crazy looking for an error in foo.pl when it really originates in Foo.pm. Besides, it'll be a pain trying to figure out the correct $CarpLevel value if you have metethods within Foo.pm call other methods who call other methods...that eventually generate the error.

If your error messages are intended toward the foo.pl user, who may not be a Perl programmer, then Carp's output will really going to confuse them no matter what the trace is. The user really only needs to know the error message, not what line the error occurred on. I'd suggest a cleaner output of error messages for them, holding their hand, and telling them that everything's going to be OK--not spitting out line numbers and script names.

BTW, if you're doing this with a CGI script, check out Ovid's warnings on using CGI::Carp at http://www.easystreet.com/~ovid/cgi_course/lesson_three/lesson_three.html.

Comment on Re: Confusion about properly using Carp

Replies are listed 'Best First'.

Re: Re: Confusion about properly using Carp
by steves (Curate) on Mar 02, 2002 at 17:17 UTC

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.

[reply]


The stupid question is the question not asked
	PerlMonks