PHP 4.0 Bug #8294 Updated: Documented behavior of @ operator does not match actual behavior

ID: 8294 Updated by: waldschrott Reported By: zak@php.net Status: Open Bug Type: Documentation problem Assigned To: Comments: 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 Previous Comments: --------------------------------------------------------------------------- [2000-12-16 12:11:30] 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. :) --------------------------------------------------------------------------- Full Bug description available at: http://bugs.php.net/?id=8294