On 06/23/2012 04:06 PM, Stas Malyshev wrote: > Hi! > >> Maybe it is simply time to rethink the error handling. > > This is true, current error handling has many deficiencies and is also > very expensive even when the errors are muted (we still produce the > whole error string, etc. even if we never display it). Unfortunately, BC > concerns prevailed last times we tried to fix it, but maybe somebody has > new ideas on that.
Yes, I think we need to rethink warnings for the cases where the error is part of the common use case. htmlspecialchars() getting passed invalid Unicode chars, json_decode() getting non-json and json_encode() getting non UTF-8 chars. These are all cases where if the function generates an error, in order to avoid that error you have to do some work beforehand to sanitize the input data which is a useless thing to have to do since the functions themselves can do it. For json_decode() we have json_last_error() to help with debugging. Maybe a solution is to generalize that. We already mostly have it via $php_errormsg/error_get_last(). And yes, I don't think a warning from json_encode() is useful because to properly avoid it you would need an iconv() call before calling it and that is pure overhead. Short of that your only recourse is to use @ and that just isn't the right answer. In this I would suggest just having it return false and have json_last_error() apply to json_encode() as well. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
