On Fri, August 28, 2009 4:09 pm, Stanislav Malyshev wrote: > Hi! > >> I foresee a fair number of people who turn on error_mask, and then >> are >> defuddled by the 3rd party apps they never reviewed in the first >> place >> not behaving. > /.../ > > All that said: > > I am in favor of this patch, provided sufficient effort to be sure > the > > community knows, in advance, loud and clear, it's not a cure-all > and > > is meant only for code that can't/won't be fixed, rather than code > > that is in active development. > > As I already noted, the masking - in most cases and definitely in > recommended cases - would happen for errors that are NOT SEEN. Not > reported. Not logged. Before the patch. Which means, whatever > advantage > you seek from looking at these errors, fixing them, reviewing the > code, > doing anything related to them at all, etc., etc. - you have ALREADY > lost if when you decided not to report these errors. Without the > patch. > Before the patch. So all arguments about how wrong it is to disable > errors when errors in fact might be useful are, again, irrelevant - > they > are already disabled without the patch.
I understand, really I do... And I know you understand, because you've repeated it. A lot. :-) I'm saying you have a big EDUCATION of community issue on your hands before releasing this feature, because if this many folks on @internals aren't getting it, and are making senseless knee-jerk arguments... Then you have millions of developers, and I use the term loosely, that will slaver over 300% performance boost and turn it on without having the faintest idea what it does... BREAKING the code that relies on custom error handlers, or that check $php_errormsg Those are the only sticking points for me. Let me give you a real-world pragmatic scenario: If I released "good" code with a custom error handler that gracefully and sensibly handled errors even if somebody was dumb enough to turn off error-reporting, and your patch breaks that, and then I get a zillion bug reports, I'm going to be a bit unhappy, and justifiably so. I think there more than a few developers who fit the above scenario, and the only way to avoid it is to be sure end users who install all kinds of crap next to my fabulous software [tongue firmly in cheek] and then use your new feature to shut up the bad software... I don't want to have to deal with a thousand bug reports because your patch encouraged the naive user to disable my error handling. Hope that clarifies the issue I'm forseeing... Again, I actually think you've made a good enough case for this. I just think your "patch" needs a lot of non-code changes. Better than average documentation. Changes to bug-reporting page. Comments in php.ini that clearly state that turning it "on" is BAD in general. . . . -- Some people ask for gifts here. I just want you to buy an Indie CD for yourself: http://cdbaby.com/search/from/lynch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
