error messages without program names or line numbers
EvanK
created: 2006-08-04 11:42:03
This might sound like a strange one, but I need to have all the errors that display in the CGI interface of my program to NOT have the script name or line numbers. For example, I'm using [cpan://CGI::Carp] to intercept any fatal errors:
use strict;
use CGI::Carp qw/fatalsToBrowser set_message/;

BEGIN {
  sub die_nice { # this will intercept any fatals
    my $err = shift;
    print "\n\n

Custom CGI Error

\n"; print "
$err
\n"; print "[script-specific error/dump info goes here]\n"; print "\n\n"; warningsToBrowser(1); } set_message(\&die_nice); } die('[this is the message passed to die]');
Now, running this code would (more or less) produce this in my browser:
[this is the message passed to die] at /home/evan/dietest.cgi line 18.
The thing is, once I put it into production, I'd only want the users to see [this is the message passed to die] while the full error would still appear in the apache error log. the only way I can think of doing this is to filter the error message like so:
sub die_nice {
  my $err = shift;
  $err =~ s/ at \S+ line \d+//g
  
  print "\n\n

Custom CGI Error

\n"; print "
$err
\n"; print "[script-specific error/dump info goes here]\n"; print "\n\n"; warningsToBrowser(1); }
This will work, mind you (im using it right now), but it seems like a hacky solution, plus what if the regex matches some other part of a strangely worded error...is there a Better Way™?

__________
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
- Terry Pratchett

Re: error messages without program names or line numbers
created: 2006-08-04 11:50:09

If you append a newline to the message you pass to die then it will not append the extra info. This convention is honoured by Carp and by implication probably by CGI::Carp also.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
Re^2: error messages without program names or line numbers
created: 2006-08-04 11:54:58

If you append a newline to the message you pass to die then it will not append the extra info.

But then the extra info won't be in the log either. Still ... I suppose you can have some variation of this?

warn($_), die "$_\n" for 'my error message';

print "Just another Perl ${\(trickster and hacker)},"
The Sidhekin proves Sidhe did it!

Re^3: error messages without program names or line numbers
created: 2006-08-04 12:30:46
Both excellent points, ++ to both of you, but the bigger problem (as I admittedly should have elaborated on) is how to catch errors I don't have dominion over?

For instance, a database error with RaiseError turned on will display a whole mess of crap.

of course, i think compile-time and/or syntax errors may occur before CGI::Carp can catch them, but I'm more concerned with outside forces, such as assorted modules.

__________
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
- Terry Pratchett

Re^4: error messages without program names or line numbers
created: 2006-08-04 13:21:04

Odds are, if you pass errors from modules you didn't write, you're leaking information to the user that they either won't understand, or they will understand, and can potentially use to exploit the system.

I'd recommend trapping all errors, and sending them to the error log, but sending a generic message to the user. (hopefully something more than 'something went wrong ... contact the system administrator'). You might trap and leave a different generic message in different sections of your code.

Depending on what the site's doing (and how locked down it is in the first place), I might hide a more useful error code/message in the source, but typically, the error page is a feedback form to alert the sysadmin -- they can leave contact information if they wish, but I can also poll for HTTP_USER_AGENT and the like, and ask them what they were doing at the time it gave them problems.

And I think it goes without saying -- if you're likely to error out due to database connections, don't track this in the database, and if you're likely to error out from writing files, don't write it to a log file w/out some other form of backup. Mail is usually good, so long as the partition w/ the mqueue doesn't fill up. (and you watch it to make sure mail's actually flowing)

Re^4: error messages without program names or line numbers
created: 2006-08-04 16:08:51
In that case you can wrap an eval {...} block around calls to suspect external subs (or anywhere else). Error messages will be passed into $@ ($EVAL_ERROR) and you can do with them what you like. Either test for undef returned by eval, or $@ for a non-empty string, both of which indicate an error has occured.
Re: error messages without program names or line numbers
created: 2006-08-04 16:31:14
Hi EvanK,
premature death in a CGI script tends to cause server errors when the proper HTTP header doesn't get out to the server before the program pegs out.
. the function carpout redirects the warnings & errors to the filehandle specified in script.
Re^2: error messages without program names or line numbers
created: 2006-10-14 10:09:37

From Chapter 32.5 of Programming Perl Version 3 "CGI::Carp":

The module is also kinder to web surfers, since premature death in a CGI script tends to cause inscrutable "Server 500" errors when the proper HTTP header doesn't get out to the server before your program pegs out, and this module makes sure that doesn't happen.  The carpout function redirects all warnings and errors to the filehandle specified.

perladdict, please be careful to attribute sources when you are quoting them, otherwise it might tend to appear that you are taking credit for words which were not originally yours.


s''(q.S:$/9=(T1';s;(..)(..);$..=substr+crypt($1,$2),2,3;eg;print$..$/

perlmonks.org content © perlmonks.org and BrowserUk, cdarke, EvanK, jhourcle, liverpole, perladdict, Sidhekin

prlmnks.org © 2006 edmund von der burg (eccles & toad)

v 0.03