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?
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 @, etc. - because in that particular context these errors are not useful. However there is no way to have the engine not to do all the work it does on the errors - even if you *know* you don't want this error to be displayed. There are a lot of completely legitimate cases where you want some errors temporary or permanently suppressed - but right now you don't have any means to do that, since error_reporting does not suppress the whole generation process, but only the very last stage of reporting. Which, frankly, makes very little sense - if you don't ever want to report it, why generate it?
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. 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. So one may preach that shouldn't happen as much as one wants, and call it "abuse" as much as one wants, but that's what happens and that's what will always happen. The question is only if people's sites would run slow or run faster. I don't see any gain in denying people means to run their sites faster.
-- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
