On 28.08.2009, at 22:47, Richard Lynch wrote:
I must say, however, that buried in Stas' use case, 3rd party, not-so-clean code, and realistic pragmatic installs thereof, is buried the rather large problem: Many people who do such a thing, do not really do a serious code-review of the 3rd party code.
Right and even so .. why should using that 3rd party code make it sensible to flip this switch on everything? I am not really suggesting the following because I havent thought it out .. just an example of out of the box thinking we need in order to try and really address the root causes. Maybe we rather need some way to define error handling on a per directory basis. This way you could just mark this 3rd party lib to use a different error reporting mode. Maybe this could be expanded even more to also cover the ever increasing number of extensions that optionally throw exceptions. This way we might even be able to reconcile the issue that if you run PDO and one lib wants exception mode and the other doesnt, you need two PDO instances.
Another, again not fully thought out approach, would be to do something along the lines of exceptions. A magic object which can carry some more context but still returns true on a === false check. This object would of course have to be super lightweight and it should just contain the necessary bits in order to be able to generate the full error message if needed. I guess that would still probably not solve the performance "issue" that Stas is trying to solve, since its hard to imagine that such a solution would not come with so much overhead that it speed up anything. However it might provide for a better solution to deal with providing error context information without forcing everybody to deal with try/catch.
Anyways, so yeah I am squarely in the camp that believes that adding more tools to just forget about error reporting is bad mojo.
I also very much agree that many functions do not use the right reporting level and that several functions could probably be made to make it easier to avoid those reports to begin with, though yes there are cases where there is simply no way to avoid them.
regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
