PHP 4.0 Bug #8294: Documented behavior of @ operator does not match actual behavior
| From: | zak@php.net | Date: | Sat, 16 Dec 2000 17:11:30 +0000 |
| Subject: | PHP 4.0 Bug #8294: Documented behavior of @ operator does not match actual behavior | ||
| Groups: | php.dev | ||
| Request: | Send a blank email to php-dev+get-41597@lists.php.net to get a copy of this message | ||
From: zak@php.net
Operating system: n/a
PHP version: 4.0.3pl1
PHP Bug Type: Documentation problem
Bug description: Documented behavior of @ operator does not match actual behavior
The documentation states that the @ operator suppresses all errors.
However, lines like:
@ error_reporting E_ALL);
still generate parse errors.
I think that the current behavior is the right thing to do - AFAIK, there is no way to induce a
parse error at runtime. Parse errors in the code that makes up the arguments for eval() and
create_function() are caught and handled differently then normal parse errors (at least AFAICT they
are - @ suppresses the errors generated in this fashion).
The only real case that I can think of where you might have parse errors at runtime would be
situations where you are dynamically including code from untested files -- if you are doing that
though, then catching parse errors is probably the least of your worries. :)
--
Edit Bug report at: http://bugs.php.net/?id=8294&edit=1