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 > >
