Roman Neuhauser wrote: > # 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] > Roman - you make some very good point but the pragmatist in me says of your first example - why the F*** would anyone pass in an object and blindly push it through printf() ?? that sucks as far as code goes (personally evening being so diligent as to implement __toString() on the relevant class is asking for bad news - too much magic imho) if the function should be capable of taking an object or a string it should check what it recieves. the way I see it this is bad code by design - and needs to be fixed. > 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: true - but then it would force someone to use exceptions - the overall consensus went against forcing that on people. > > 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. that is a good point - from what I've read that will probably be implemented very soon (pity it missing now though) > > 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. > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
