On Mon, May 24, 2010 at 2:12 PM, Brian Moon <br...@moonspot.net> wrote: > Because that is, IMO, a bad precedent to start for PHP internal functions. > Too many functions already produce warnings (fopen) and return a status that > can be checked. The solution right now is @ and that has so much baggage > with it that you can now disable that feature completely making distributed > software not be able to deal with these functions and return useful messages > instead of spewing warnings uncontrollably. I am all for turning off > warnings when a function returns a success/failure status.
And when this success/failure status is actually being used in the calling code I assume? ;-) > > Brian. > -------- > http://brian.moonspot.net/ > > On 5/22/10 9:42 AM, Ilia Alshanetsky wrote: >> >> Instead of removing a warning, why not add an additional parameter to the >> function that would instruct it to silence warning messages on parse >> failure? >> >> On Fri, May 21, 2010 at 11:55 AM, Brian Moon<br...@moonspot.net> wrote: >> >>> +1 >>> >>> >>> Brian. >>> -------- >>> http://brian.moonspot.net/ >>> >>> >>> On 5/21/10 10:38 AM, Ralph Schindler wrote: >>> >>>> >>>> Hey all, >>>> >>>> Attached is a patch to remove the warning from parse_url() in situations >>>> where parse_url() cannot actually parse the url. The bug report also >>>> claims there should be a new feature for understanding "why" a parsed >>>> url failed. That code currently does not exist, and the current warning >>>> gives no more information than simply returning false does. >>>> >>>> http://bugs.php.net/bug.php?id=50563 >>>> >>>> The first patch is against trunk. I think we should at least get this >>>> done even if the group decides that down the line we want the why >>>> portion explained as well (I actually don't care about the why part). >>>> That feature would require that php_url_parse_ex() add some parsing >>>> intellignce, this would not be a 1 or 2 line feature implementation. >>>> >>>> The motivation is that since false and E_WARN are redunant, this patch >>>> would allow developers to STOP using @parse_url(), which we have to do. >>>> >>>> I also suggest that we apply this to the PHP_5_3 branch. This behavior >>>> should be backwards compatible with everyone that is actually using the >>>> @parse_url() in their code. The only 1-off situation that might be >>>> affected is if people are catching the error with an error handler and >>>> branching there. Why they wouldn't be branching off the false return >>>> value, I don't know. >>>> >>>> Both patches contain test fixes. >>>> >>>> Is there anything more I need? Is this commit worthy? >>>> >>>> Thanks, >>>> Ralph >>>> >>>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> >> > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- -- Tjerk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
