Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re^2: error messages without program names or line numbers

by Sidhekin (Priest)
on Aug 04, 2006 at 15:54 UTC ( #565683=note: print w/ replies, xml ) Need Help??


in reply to Re: error messages without program names or line numbers
in thread error messages without program names or line numbers

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!


Comment on Re^2: error messages without program names or line numbers
Select or Download Code
Re^3: error messages without program names or line numbers
by EvanK (Chaplain) on Aug 04, 2006 at 16:30 UTC
    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

      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)

      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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://565683]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (6)
As of 2014-07-24 23:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (167 votes), past polls