Bug #60954 [Com]: error_reporting() = 0?

From: Date: Thu, 02 Feb 2012 22:30:00 +0000
Subject: Bug #60954 [Com]: error_reporting() = 0?
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-167077@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=60954&edit=1

 ID:                 60954
 Comment by:         anon at anon dot anon
 Reported by:        aei at riga dot ahlers dot com
 Summary:            error_reporting() = 0?
 Status:             Open
 Type:               Bug
 Package:            PHP options/info functions
 Operating System:   Gentoo Linux (x86_64-3.1.7)
 PHP Version:        5.3.9
 Block user comment: N
 Private report:     N

 New Comment:

>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.


Previous Comments:
------------------------------------------------------------------------
[2012-02-02 13:53:29] 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



------------------------------------------------------------------------



-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60954&edit=1


Thread (4 messages)

« previous php.bugs (#167077) next »