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