PHP 4.0 Bug #7473 Updated: @ not affecting error_handler

ID: 7473 Updated by: david Reported By: david@php.net Status: Closed Bug Type: Scripting Engine problem Assigned To: Comments: Thank you, I have updated the docs. Previous Comments: --------------------------------------------------------------------------- [2000-11-05 11:37:34] stas@php.net error_reporting() (without arguments) will return error reporting setting. It will return 0 if it's under @. Does it fit your needs? --------------------------------------------------------------------------- [2000-11-01 03:32:24] david@php.net If I call a function, and that function raises an error/warning, then error-control operator @ would usually prevent the "standard" PHP error handler from printing anything out. However if I am using a custom error handler, it does not prevent the handler being called. An example/reproducing script with the "variable passed to reset() is not an array or object" error: <? $a = 1; reset($a); // A @reset($a); // B function custom_error_handler($errno, $errmsg, $errfile, $errline) { echo "Error handler: $errmsg at line $errline of $errfilen"; } set_error_handler('custom_error_handler'); reset($a); // C @reset($a); // D ?> (A) triggers the standard error message as expected. (B) "silences" the standard error message as expected. (C) triggers the custom error handler as expected. (D) triggers the custom error handler, ignoring the @. (D) is my problem, as the @ is being ignored here, and the custom error handler is being called anyway. Now it may be that you have a good reason for wanting the custom error handler to be called despite the error-control operator being used. In that case I would suggest that you allow the custom error handler to detect whether the "@" prefix was used, perhaps with an addition optional parameter "bool $errorcontrol_prefix" being passed to the function. This would be true if the error in question would normally have been supressed because of the "@". Thanks --------------------------------------------------------------------------- [2000-11-01 02:49:20] david@php.net If I call a function, and that function raises an error/warning, then error-control operator @ would usually prevent the "standard" PHP error handler from printing anything out. However if I am using a custom error handler, it does not prevent the handler being called. An example/reproducing script with the "variable passed to reset() is not an array or object" error: <? $a = 1; reset($a); // A @reset($a); // B function custom_error_handler($errno, $errmsg, $errfile, $errline) { echo "Error handler: $errmsg at line $errline of $errfilen"; } set_error_handler('custom_error_handler'); reset($a); // C @reset($a); // D ?> (A) triggers the standard error message as expected. (B) "silences" the standard error message as expected. (C) triggers the custom error handler as expected. (D) triggers the custom error handler, ignoring the @. (D) is my problem, as the @ is being ignored here, and the custom error handler is being called anyway. Now it may be that you have a good reason for wanting the custom error handler to be called despite the error-control operator being used. In that case I would suggest that you allow the custom error handler to detect whether the "@" prefix was used, perhaps with an addition optional parameter "bool $errorcontrol_prefix" being passed to the function. This would be true if the error in question would normally have been supressed because of the "@". Thanks --------------------------------------------------------------------------- [2000-11-01 02:33:08] andi@php.net You should elaborate on what your concern is. I don't quite understand it. Do you have a reproducable bug script? --------------------------------------------------------------------------- [2000-10-25 23:57:28] david@php.net It may be for a good reason that @ does not prevent the error_handler being called. However if this is true, then it should please be possible for the error_handler to determine whether the function call generating the error was prepended by @. --------------------------------------------------------------------------- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. Full Bug description available at: http://bugs.php.net/?id=7473