Date: 12/16/00
- Next message: Phil Driscoll: "Re: [PHP-DEV] Re: [PHP-QA] RC6 ISAPI problems"
- Previous message: ryan <email protected>: "[PHP-DEV] PHP 4.0 Bug #8298 Updated: Apache segfaults with php module loaded."
- In reply to: waldschrott <email protected>: "[PHP-DEV] PHP 4.0 Bug #8294 Updated: Documented behavior of @ operator does not match actual behavior"
- Next in thread: André Langhorst: "Re: [PHP-DEV] PHP 4.0 Bug #8294 Updated: Documented behavior of @ operator does not match actual behavior"
- Reply: André Langhorst: "Re: [PHP-DEV] PHP 4.0 Bug #8294 Updated: Documented behavior of @ operator does not match actual behavior"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I did not state that the behavior of the operator was was a problem. :)
I stated that the documentation does not match how the operator behaves. I
also noted that I thought that the current behavior made sense...
Is this not clear?
--zak
----- Original Message -----
From: <waldschrott <email protected>>
To: <php-dev <email protected>>
Sent: Saturday, December 16, 2000 12:11 PM
Subject: [PHP-DEV] PHP 4.0 Bug #8294 Updated: Documented behavior of @
operator does not match actual behavior
> ID: 8294
> Updated by: waldschrott
> Reported By: zak <email protected>
> 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 <email protected>
> 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
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
> For additional commands, e-mail: php-dev-help <email protected>
> To contact the list administrators, e-mail: php-list-admin <email protected>
>
-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe <email protected> For additional commands, e-mail: php-dev-help <email protected> To contact the list administrators, e-mail: php-list-admin <email protected>
- Next message: Phil Driscoll: "Re: [PHP-DEV] Re: [PHP-QA] RC6 ISAPI problems"
- Previous message: ryan <email protected>: "[PHP-DEV] PHP 4.0 Bug #8298 Updated: Apache segfaults with php module loaded."
- In reply to: waldschrott <email protected>: "[PHP-DEV] PHP 4.0 Bug #8294 Updated: Documented behavior of @ operator does not match actual behavior"
- Next in thread: André Langhorst: "Re: [PHP-DEV] PHP 4.0 Bug #8294 Updated: Documented behavior of @ operator does not match actual behavior"
- Reply: André Langhorst: "Re: [PHP-DEV] PHP 4.0 Bug #8294 Updated: Documented behavior of @ operator does not match actual behavior"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

