php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #60954 error_reporting() = 0?
Submitted: 2012-02-02 13:53 UTC Modified: 2012-02-03 00:44 UTC
From: aei at riga dot ahlers dot com Assigned:
Status: Wont fix Package: PHP options/info functions
PHP Version: 5.3.9 OS: Gentoo Linux (x86_64-3.1.7)
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: aei at riga dot ahlers dot com
New email:
PHP Version: OS:

 

 [2012-02-02 13:53 UTC] aei at riga dot ahlers dot com
Description:
------------
---
From manual page: http://www.php.net/function.set-error-handler#refsect1-
function.set-error-handler-parameters
---

In the manual, it is written:

error_reporting() settings will have no effect and your error handler will be 
called regardless - however you are still able to read the current value of 
error_reporting and act appropriately. <b>Of particular note is that this value 
will be 0 if the statement that caused the error was prepended by the @ error-
control operator.</b>

Is there any particular reason why error_reporting() should return 0 if the 
statement that caused the error was prepended by the @ error-control operator?  
I mean, if errors are handled by a custom error handler callback set by 
set_error_handler(), there is currently no easy way to get current value of 
error_reporting(), right?  Because inside error handler callback function it may 
just return 0.  If we want to log or not log entries into a custom error log 
within this callback function depending on the setting of error_reporting, we're 
unable to do so in situations when '@' was used before the statement that caused 
error?  We could of course save value of error_reporting() in the beginning of 
our script to a global variable and use it from within the error call back 
function, but why?

Thanks,

Andrejs


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-02-02 22:30 UTC] anon at anon dot anon
>Is there any particular reason why error_reporting() should return 0 if the 
statement that caused the error was prepended by the @ error-control operator?  

Well for one thing it's the quick 'n' dirty way to make the error handler function be quiet to implement the @ operator, and PHP usually chooses the quick 'n' dirty route.

I think it's right though. If you're @ing an expression, it's because you want to ignore errors in it. Such an error shouldn't be printed or logged except during debugging, because many PHP functions raise an error as part of their normal operation. Consider a call to fopen: Code is expected to look at the return value to see if the file opened successfully and handle it as necessary. In that case, it may not want the fopen error message to be printed/logged, since the user code may raise its own more specific error, or it might not be an error at all (if it was merely testing if the file could be opened in the given mode, or it can handle the intended file operation in another way).

Because @ applies to complete expressions (which can include calls of entire large functions and everything they do) it's sometimes too aggressive, in which case you'd want to disable @ by using a custom error handler function. Apart from that debugging case, when you can easily hard-wire an error reporting value into the handler function, you shouldn't really need to differentiate between the base error reporting value and the @ value. I'm curious why you want to.
 [2012-02-02 23:00 UTC] aei at riga dot ahlers dot com
Well, I am talking about the situations when external error handler is used.  
Suppose we want to catch any errors inside our script using a custom error 
handler function, but we also want to respect error_reporting settings provided 
by the configuration so as to show/log an error or not.  Suppose the current 
error_reporting level = E_ALL & ~E_DEPRECATED & ~E_NOTICE (22519), Now, inside 
our custom error handler function we would need to be logging all errors except 
deprecated and notice-level, so as to respect error_reporting setting.  It seems 
to be so simple:


function default_error_handler($errtype, $errstr, $errfile, $errline) {  
  if ((error_reporting() & $errtype) == 0) {
    return FALSE; // only handle errors specified by PHP configuration
  }  
  log_write(sprintf('Error: %s in %s at line %u',
    $errstr, $errfile, $errline));
  ... 
}

Unfortunately, since error_reporting() returns 0 for calls that were prepended 
by a '@', those errors will never get logged as we wanted.  Don't you think if 
we instruct PHP interpreter that we want to use our own error handler function, 
we would also like to control we might want to respect PHP error_reporting 
settings when displaying errors?  In my opinion, it makes logical sense.

The solution would be if there was a possibility to know that the failed 
statement was prepended with '@', so we could know what to do about it in our 
custom error handler, while error_reporting() would always return current level 
of error reporting?

Andrejs
 [2012-02-03 00:44 UTC] aharvey@php.net
-Status: Open +Status: Wont fix
 [2012-02-03 00:44 UTC] aharvey@php.net
There is actually a good technical reason for this, which is that internally the @ 
operator causes PHP to change the error_reporting value. In effect writing this:

@foo(42);

Really means this in effect on an engine level:

old_error_reporting = error_reporting(0);
foo(42);
error_reporting(old_error_reporting);

In theory it would be possible to expose the value of old_error_reporting to 
userspace when within a silence operator, but in practice, it would add complexity 
to the engine for little practical gain.

Closing won't fix.
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Mon Jul 22 11:01:25 2019 UTC