Forum Moderators: coopster

Message Too Old, No Replies

Which errors can I safely ignore

         

Nutter

12:27 pm on Jul 5, 2007 (gmt 0)

10+ Year Member



I'm working on an error handler for an application of mine and looking for what error levels I can safely ignore and which I need to alert the user to, and possibly which I should not show the user but log.

I assume I can ignore E_WARNING since the only errors I've seen of that level are undefined variables.

What about E_STRICT? My understanding is that PHP is suggesting code changes that would make my code more future proof, but aren't causing problems right now. The only one I've come across is that var is deprecated, although I still need the code to work with PHP4 so I need to use var.

All the others, including the E_USER set because some of my classes throw user errors, seem to need to stop execution. I would rather have a non-fatal error display a clean page with an error message than have the non-fatal message sporadic through the page.

coopster

12:56 pm on Jul 5, 2007 (gmt 0)

WebmasterWorld Administrator 10+ Year Member



I don't ignore any errors, not even NOTICE or WARNING errors. Every error should be noted and fixed or at least handled in some way.

You don't need to check for STRICT errors in PHP4 code versions, but if you are developing in PHP5 you should watch for them. Many classes, as you have noted, will generate STRICT errors if they are written to work in PHP4 installations. Those specific to PHP5 should check for STRICT errors and be cleaned up too.

RonPK

1:30 pm on Jul 5, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



I assume I can ignore E_WARNING since the only errors I've seen of that level are undefined variables.

Maybe you're confusing notices with warnings. An undefined variable will throw a notice (

$var .= 'bla'
, without first defining $var). A warning usually means something is not working. For example, on my Windows box
mail()
always leads to a warning, as there is no mailing software available to PHP.
include(non-existing file)
will also cause a warning. The script will carry on after a warning, but the result might not be what you'd expect...

Nutter

2:20 pm on Jul 5, 2007 (gmt 0)

10+ Year Member



You're right I got those two mixed up. I meant E_NOTICE.

I don't ignore any errors, not even NOTICE or WARNING errors. Every error should be noted and fixed or at least handled in some way.

I understand the idea of needing to see the errors during development, but I'd prefer that $_SESSION['varabel'] when I meant to read $_SESSION['variable'] not display an error to the end user. My real problem is that I wrote a lot of this code using if ($_GET['p']=='whatever') when $_GET['p'] may or not be set and I really don't want to go back and fix it everywhere I did that.

And I agree that every error should be handled, but isn't looking at the error and deciding that the user doesn't need to see that I didn't declare $x before using it and that the code can just go on without displaying an error handling the error?

eelixduppy

4:57 pm on Jul 5, 2007 (gmt 0)



All errors should be logged and not output to the browser on a production server. The display errors [us.php.net] directive should be turned off, and the log errors [us.php.net] directive should be turned on to log the errors in the appropriate error log [us.php.net].

Nutter

10:25 pm on Jul 5, 2007 (gmt 0)

10+ Year Member



That's actually part of the problem I'm having. When a server is setup so that errors are not displayed, all my users get is a white screen if there's a problem. That's what prompted this to begin with. I wanted some sort of message so that I could try and figure out what's going on, and I think I'm almost there.

eelixduppy

10:33 pm on Jul 5, 2007 (gmt 0)



PHP has error handling functions [us.php.net] that you can use. If an error occurs, redirect them to an error page and log the error in the error log.

Nutter

4:15 am on Jul 6, 2007 (gmt 0)

10+ Year Member



The error handling functions are actually what started me down this road. I wound up with a series of functions that looks at the error message, displays a message to the user and stops execution if necessary, writes to a log file, and tries to continue if possible. It's certainly better than what I had been doing which was nothing.

I guess the real question is... are there E_NOTICE or E_STRICT warnings that will cause problems in a production site other than just not being technically correct? Yes, I know that if ($_GET['something']=='123') can cause a notice but the code still functions. Same thing with using var $x in a class on a PHP5 server. An E_STRICT warning comes up but ignoring it doesn't seem to cause a problem.

Or is there a list of all, or a pretty good chunk of, the various errors messages broken down by type?

RonPK

8:39 am on Jul 6, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



The manual [nl3.php.net] is a bit vague on notices: "Run-time notices. Indicate that the script encountered something that could indicate an error, but could also happen in the normal course of running a script."

I've never had any big problems with notices, except in situations where they are output to html and may break header().

But here's a problem scenario: a lazy coder who always writes

$array[foo]
in stead of
$array['foo']
. "Hey, it works, and I read on WebmasterWorld that I can safely ignore those pesky notices." But one day he or a co-worker introduces a new constant somewhere else in the application:
define('foo', 'bar')
. Suddenly problems galore.