Re: E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



# jochem@xxxxxxxxxxxxx / 2007-01-03 14:07:31 +0100:
> 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.

Well, why the F*** would anyone use a language that allows you to pass
incompatible objects to a function and crashes when you do so? ;)

Errors and warnings are fine for languages where the compilation step is
separate from the run. For a language like PHP, anything but
"RuntimeException" means your perfectly correct code can crash at
runtime, without you having a slightest chance to react (in the code).

> > 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.

I don't follow the logic. What did we gain? Can one of those "exceptions
== Java, Java stinks, exceptions stink" campers show me their version of
the below f($any) that works in 5.1 and 5.2?

-- 
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


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux