On 24-Aug-09, at 3:30 PM, Stanislav Malyshev wrote:
Hi!
1) Once you completely hide an error there is absolutely no trace
what so ever that it has even occurred, even if its the slowdown of
the native error handler being.
That's the point. And how the slowdown would be useful?
Because it may force to fix the errors, rather then ignore them?
2) Debugging code becomes that much more trickier, since a single
option effectively turns off PHP's error handling completely.
That's not correct. It doesn't turn off php error handling - it
allows you to specify which errors you handle and which not. That's
what error_reporting should be doing from the start, but it does
not. Of course, if you want notices, etc. to be displayed - display
them, nobody prevents you from doing so and you can see the default
is very permissive. But right now there's no way to save the
busywork that happens on errors that you *don't* want to be
displayed. How it helps your debugging if PHP allocates a bunch of
memory, spends the cycles and throws out the result without ever
keeping it anywhere?
As far as I can tell the only benefit of this patch is to allow
error prone code to run faster by avoiding the slow down of
generating error message strings when errors occurs, but the
downside is abuse by people who just want errors to go away... IMHO
the downside outweighs the upside.
This is not correct. There is a lot of code that deliberately
ignores errors - with @
There is very little modern code that is @ ridden like the stuff
written before. The way to have the engine not do the work, would be
as simple as fixing the code, which is the right solution here.
As for "abuse" - by which you mean running code with errors disabled
I guess - everybody that ever ran third-party code in production
knows that it is an everyday reality that a lot of code out there is
not E_NOTICE-safe, even more is not E_STRICT/E_DEPRECATED/etc. safe.
The production value we use according to php.ini-production is E_ALL &
~E_DEPRECATED, which means E_NOTICE will not be hidden.
And production settings - including ones we recommend - do not
include reporting these errors. So they serve absolutely no useful
purpose but spending cycles on useless work - humans never see them,
nobody debugs them, only thing they do is waste time.
Well, if you are going to hide them, the no one will ever debug them,
let alone know that they exist.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
