# jochem@xxxxxxxxxxxxx / 2007-01-02 21:23:02 +0100: > David CHANIAL wrote: > > We are preparing the upgrade of PHP for our customers, but, after some tests, > > we have a migration "problem" caused by the news E_RECOVERABLE_ERROR. > > > > So, even if the upgrade guide (http://www.php.net/UPDATE_5_2.txt) talk about > > the method to handle this new errors (by using try/catch), they don't talk > > there is no mention of try/catch - it seems that the rather unfortunate word > 'catchable' was used to describe the act of setting up a user defined error handler > (see: http://php.net/manual/en/function.set-error-handler.php) to handle errors > that are triggered by the php core. [errors != exceptions] Unfortunately. Consider this: function f($any) { printf("%s\n", $any); } Innocent enough? It's an E_RECOVERABLE_ERROR if $any is an object without __toString(). The 5.2.0 changelog talks about problems with the textual representation (object #id), but this cure is IMO worse than the disease, especially as they didn't make it an exception which would be *much* easier to handle: function f($any) { try { printf("%s\n", $any); } catch (CastError $e) { printf("%s\n", spl_object_hash($any)); } } In fact, I wonder why spl_object_hash() hasn't replaced the old default behavior. One way to (almost) handle this (or indeed warnings in PHP at all) is to use an error_handler that mutates all it can into exceptions. Unfortunately, you can only do this if there's no independently developed code in the program. If it uses a library that's not written for a throwing error handler, such a handler will change the library's semantics! Imagine a DB library that contained this code: if (false === ($conn = mysql_connect())) { handle_error(); } handle_error() will never be called with a throwing error handler. And you cannot use such a handler in the library either, because the application would have to defend against the library error handler leaking e. g. into signal handlers. Also, if every library had to install/deinstall its own error handler on every entry and exit of its code... I don't want to even think of that. To me, E_RECOVERABLE_ERROR, or at least some of its instances, seem to be more of an interoperability problem than anything else. But that's IMO true of the whole error handling in PHP. Now back to our regularly scheduled pushing files around t3h 1nt3rn3t. -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
