Re: E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0

# jochem@iamjochem.com / 2007-01-03 14:07:31 +0100: > Roman Neuhauser wrote: > > # jochem@iamjochem.com / 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: ¶‰¼ŒÕ  > >> 0@ÿ6a9bõ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