Hi,
I think the idea is good intended but will cause troubles of introduced in
5.3. I alone have a bunch of code with custom error handlers that expect to
receive all errors at all times. If the feature allows runtime tweaking via
ini_set/get, then one could add more plumbing code and workaround, but it
still doesn't make it BC to the expected behavior for existing 5.x apps.
However I fully agree E_NOTICE should:
1) be reserved for informational may-be-bad-but-usually-is-ok messages
2) not have performance impact when disabled (i.e. production)
The problem? Right now important errors that could cause data damage if
ignored are E_NOTICE instead of E_WARNING.
I'm talking E_NOTICE when you using variables that don't exist, missing
constants and so on. All of this should be E_WARNING so my production code
can stop and notify me when it's encountered, then I wouldn't mind filtering
E_NOTICE.
Also Stas, consider why are you trying to treat the symptom of unwanted
errors slowing things down. I would bet it's something like the stream APIs
emitting errors on 404 response and such. Some API-s really throw notices
and warnings where it makes no sense, so people mute them out of necessity
(or use handlers). I'd rather fix the API-s instead of pretend it doesn't
happen by masking the errors.
All of the above would be a job for 6.0 IMHO, 5.x has pulled enough changes
under our feet and it's really not fun anymore :P
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
