[RESOLVED] Divide by Zero vs. Trigger_Error

netlynx

I have created a simple error handling class that writes an error to the database. During testing this class I noticed one thing, when I do:

trigger_error("Some warning message", E_USER_WARNING);

it writes the error message to the database properly (not displaying anything on the screen).

if I add the the following line directly after it (thus no error reporting code has changed at all):

$x=2/0;

I get "Warning: Division by zero in Unknown on line 0" on the screen output (and nothing is written to the database.

Is there something setting in the php.ini that is causing this, or what?

I should also note that I have set the following (before instantiating the errorHandler class):

error_reporting(2047); // I have also tried error_reporting(E_ALL) as well

Oersoep

"Warning: Division by zero in Unknown on line 0"

Line 0:
You didn't tell the script that you want to use your callback, did you? 🙂

In case I'm just being smart:

You've probably used set_error_handler() to set the function writing the error in the database.
When you do that, error_reporting doesn't count anymore: You'll have to make those decisions in the error handler you wrote.

From the manual:

myErrorHandler($errno, $errstr, $errfile, $errline)

echo that values and we'll see if it even gets there.

PS
Since the division by zero gives a warning I suppose it's not one of these, is it?

The following error types cannot be handled with a user defined function: E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING

netlynx

Ahh, you are absolutely right. I actually have a couple of lines in the errorHandler class as follows:

$reporting_level = error_reporting();
...
if (( $errorNumber & $reporting_level ) != $errorNumber ) {
// Do nothing, just return to the script
return;
}

In this way I can still maintain some consistancy throughout my scripts, and still change error_level reporting on the fly. (You know, sometimes when testing you want to see whats going on on the screen rather than trying to search a database).

As far as the "error types that can not be handled" quote, I did read that at one point, thanks for mentioning that, I forgot about that completely, that would explain it.