Roman Neuhauser wrote:
> # [EMAIL PROTECTED] / 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
