Re: [patch] error masks

On 24.08.2009, at 23:59, Rasmus Lerdorf wrote:

Lukas Kahwe Smith wrote:

On 24.08.2009, at 23:42, Stanislav Malyshev wrote:

Hi!

Quite boring to read this thread where two persons argue about something abstract. Stas, can you give a real life example where your patch is necessary..?

Any code where you either use @ or error_reporting which is not -1 would benefit from it by not processing errors that go nowhere. I just looked at Zend Framework - with is pretty clean with regard to E_NOTICE/E_STRICT problems - and @ is used in dozens of classes around. The speedup would be probably not very big for whole RL application, but it's a 10-line patch, and little things help too.

well a few of those places would probably be fixable, by providing functions to check beforehand if calling the final function would cause an error. but that if course would add more overhead, but would still be the "cleaner" solution. overall i am not so convinced about the ignoring approach. as for E_STRICT .. that shouldnt become less of an issue now that we have E_DEPRECATED .. but i guess that just means that in the future people will complain about E_DEPRECATED .. anyways to me both E_STRICT and E_DEPRECATED are development tools that can be totally ignored in production. however E_NOTICE should not occur in production and we shouldnt encourage people to make them disappear entirely.

Lukas, the problem is that all messages, E_STRICT, E_DEPRECATED, E_NOTICE, whatever, all cause a performance hit even if the error_reporting level is such that they will never show up anywhere. That's what this patch is trying to address. To write optimal code, they have to be entirely clean of all messages including E_DEPRECATED and E_STRICT.

right .. what i was trying to say was that i can see value in being able to hide E_DEPRECATED and E_STRICT, but the error stuff shouldnt be hidden that way. users should either display or log their E_NOTICES and fix them! regards, Lukas Kahwe Smith mls@pooteeweet.org