php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #8294 Documented behavior of @ operator does not match actual behavior
Submitted: 2000-12-16 12:11 UTC Modified: 2001-01-22 20:58 UTC
From: zak@php.net Assigned:
Status: Closed Package: Documentation problem
PHP Version: 4.0.3pl1 OS: n/a
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: zak@php.net
New email:
PHP Version: OS:

 

 [2000-12-16 12:11 UTC] zak@php.net
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. :)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-12-16 14:11 UTC] waldschrott@php.net
I do not think this is a problem, why suppress a fatal error
if your script will break at this point at any rate? use
error_reporting() then (for productional sites)

the only thing which should be documented (if not already
done) it that errors from statements will not be suppressed
 [2000-12-16 14:13 UTC] waldschrott@php.net
I do not think this is a problem, why suppress a fatal error
if your script will break at this point at any rate? use
error_reporting() then (for productional sites)

the only thing which should be documented (if not already
done) it that errors from statements will not be suppressed
 [2001-01-22 20:58 UTC] jimw@php.net
noted that parse errors can't be suppresed.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Oct 07 17:01:28 2024 UTC