Re: ext/intl

On Sun, May 10, 2009 at 20:48, Stanislav Malyshev <stas@zend.com> wrote: > Hi! > >> And even more annoying is the fact ext/intl invents its own error >> reporting completely. >> It silently fails and error message retrieval is left as exercise for >> the user, exactly the opposite of what _all_ other extensions do. > > Isn't that what is described here? > http://us.php.net/mysql_error > > Errors coming back from the MySQL database backend no longer issue warnings. > Instead, use mysql_error() to retrieve the error text. Note that this I don't remember seeing "mysql_error_set()" which does not go via php_error_docref(). No intl errors go via php_error_docref(). They all seem to go via intl_error_set() weirdness. Because the ext invents its own error handling you end up with things like: bjori@jessica:/usr/src/php/5.3$ sapi/cli/php -r 'idn_to_utf8(""); var_dump(intl_get_error_message());' string(57) "idn_to_ascii: empty domain name: U_ILLEGAL_ARGUMENT_ERROR" The example above is wrong in so manny ways: - cannot be cought with custom error handler - doesn't link to the manual - cannot be retirved with error_get_last() - $php_errormsg isn't set - it doesn't tell me lineno - and and and... Yet that error is explicitly set by the ext, not the underlying library. Also note that the function name (in the message) is wrong. >> Furthermore many of these messages are wrong, as they hardcode the >> function name to the message (see php_intl_idn_to() f.e.), rather then >> using the normal way of populating error messages. > > They report where the error happened, what harm is in that? No they don't. See explanation above. -Hannes