Roman Neuhauser wrote: > # 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). you have to pay some kind of price for dynamic typing and intepreted running. testing is done for a reason and I stand by my opinion that your given example is tantamount to awful coding and it should be corrected. granted when confronted with code that is already in the wild and your suddenly faced with such an error on a live system (due to an update) it's very very annoying (at the least) - such is life (or is that just coding?) :-) > >>> 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? probably not - i wouldn't know I don't live in that camp. > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
