Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
On Thu, January 4, 2007 8:26 pm, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2007-01-04 18:45:07 -0600: On Thu, January 4, 2007 6:17 pm, Roman Neuhauser wrote: Ok, but what harm has been done? something() presumably did the fopen() for a reason, and couldn't work without the file handle and couldn't succeed anyway. Sure, the program leaves the normal path at this moment unexpectedly, and I can understand your frustration, but it has a bug, right? And although the program contains a bug it hasn't crashed, it just entered whatever orderly cleanup-and-exit path you had prepared. If fopen() didn't throw and the programmer didn't check the return value (catch the exception in your version), you'd be screwed not even knowing it. I think you brought a solid example of superiority of exceptions over returning error codes. over returning error codes and not DOING anything with them? Sure. Over well-written code that does something with the returned error codes? no. Just a stylistic difference really, if all developers consistently did their error-checking, and did it fairly well. Alas, they don't. That's exactly the point. Programmers don't check return values, programs have bugs. Programmers don't write try/catch blocks, programs have bugs. Same thing, different spelling. And, suppose it's NOT an fopen() that was the problem deep in the guts of the other guy's code. Now you are catching an error and you have NO IDEA what the [bleep] to do with it. If you really don't know what to do, then the right thing is probably an orderly exit of the application, no? What I should have said is that you are catching an error assuming that it is caused by X when it is caused by Y, and handling it inappropriately, because you cannot tell the difference between the errors you meant to catch, and the lower-level un-caught errors. At least with error code returns, you are USUALLY dealing with a specific way to get those codes (in PHP, not C-style shell-style pass-the-buck error code bubble-up). With error codes, you are USUALLY dealing with crashes and wrong behavior. Compiled programs segfault, programs in PHP produce unspecified numbers of E_NOTICE, E_WARNING, and quite easily drop dead with an E_FATAL before returning to where you'd be complaining that you don't know what to do with the error! I know exactly what to do with those errors in set_error_handler. :-) And, of course, you just ignored the question of another catch block doing something you wish it didn't do... I don't know what that means. I don't know how else to describe it, but will make one last stab: Pretend you are using some library of software with a lot of code, and you have a lot of your own code. There are try/catch blocks all over the place. The library does something with try/catch, and you don't like the way it handles the error. It's very difficult to change that behaviour. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
# [EMAIL PROTECTED] / 2007-01-05 16:29:04 -0600: Pretend you are using some library of software with a lot of code, and you have a lot of your own code. There are try/catch blocks all over the place. The library does something with try/catch, and you don't like the way it handles the error. It's very difficult to change that behaviour. How does that differ from a situation where you're unhappy with a way a procedural library handles error situations? -- 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
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
# [EMAIL PROTECTED] / 2007-01-03 15:18:59 -0600:
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]
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().
It's also an example of a former C coder's understanding of how to do
things in PHP. Not only is this extremely inefficient (a function call
is significant overhead in PHP) it is doubly inefficient through the
unnecessary use of printf(). printf() is best used when you are
modifying the display of the output, the %s modifier by itself is
pointless in PHP.
This is utter crap.
function f($any)
{
echo $any . \n;
}
This has no E_RECOVERABLE_ERROR possibility and is far more efficient.
Better yet, replace
f($blah)
with
echo $blah . \n
echo $blah . \n is *not* equivalent to printf(%s\n, $blah)
more crap elided
--
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
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
# [EMAIL PROTECTED] / 2007-01-04 10:54:58 +:
# [EMAIL PROTECTED] / 2007-01-03 15:18:59 -0600:
Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2007-01-02 21:23:02 +0100:
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]
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().
It's also an example of a former C coder's understanding of how to do
things in PHP. Not only is this extremely inefficient (a function call
is significant overhead in PHP) it is doubly inefficient through the
unnecessary use of printf(). printf() is best used when you are
modifying the display of the output, the %s modifier by itself is
pointless in PHP.
This is utter crap.
Clarification: the last sentence is true as far as the contrived example
above. The rest of the message (suggestions that structuring code is
bad) and where it leads is without a base.
--
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
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
Gregory Beaver wrote: This is a good example of how the flexibility of PHP can bite you, but is also a good example of how bad coding adds both complexity and inefficiency to the resulting software. If f() is called often, there might be a noticeable speedup if it were replaced. I once had a complex database ORM-HTML mapping app that was about 10% faster when I replaced all the strings with '' strings. This was on a slow machine with an early PHP, but little things like this can be very important. http://dev.stut.net/phpspeed/ -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
On Thu, 2007-01-04 at 10:15 +, Stut wrote: Gregory Beaver wrote: This is a good example of how the flexibility of PHP can bite you, but is also a good example of how bad coding adds both complexity and inefficiency to the resulting software. If f() is called often, there might be a noticeable speedup if it were replaced. I once had a complex database ORM-HTML mapping app that was about 10% faster when I replaced all the strings with '' strings. This was on a slow machine with an early PHP, but little things like this can be very important. http://dev.stut.net/phpspeed/ You forgot to benchmark echo, everyone (me anyways) knows echo is faster than print. Why you ask? Because print returns a value, echo does not :) Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
On Thu, 2007-01-04 at 05:51 -0500, Robert Cummings wrote: On Thu, 2007-01-04 at 10:15 +, Stut wrote: Gregory Beaver wrote: This is a good example of how the flexibility of PHP can bite you, but is also a good example of how bad coding adds both complexity and inefficiency to the resulting software. If f() is called often, there might be a noticeable speedup if it were replaced. I once had a complex database ORM-HTML mapping app that was about 10% faster when I replaced all the strings with '' strings. This was on a slow machine with an early PHP, but little things like this can be very important. http://dev.stut.net/phpspeed/ You forgot to benchmark echo, everyone (me anyways) knows echo is faster than print. Why you ask? Because print returns a value, echo does not :) Never mind, I see it :) Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
# [EMAIL PROTECTED] / 2007-01-04 05:25:58 -0500:
On Thu, 2007-01-04 at 10:54 +, Roman Neuhauser wrote:
echo $blah . \n is *not* equivalent to printf(%s\n, $blah)
H, could you explain to me how it is different? I would always use
the former unless I specifically needed formatting provided by printf(),
and since there no formatting in the above printf() the echo to the best
of my knowledge is indeed equivalent.
That was a early-morning brainfart from me: I was thinking about
the real code, which uses
return sprintf('%s', $any);
It could be
return (string) $any;
but I prefer the sprintf() for the same reason I prefer C++-style casts
in C++ over C-style casts.
--
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
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
Robert Cummings wrote: On Thu, 2007-01-04 at 10:15 +, Stut wrote: Gregory Beaver wrote: This is a good example of how the flexibility of PHP can bite you, but is also a good example of how bad coding adds both complexity and inefficiency to the resulting software. If f() is called often, there might be a noticeable speedup if it were replaced. I once had a complex database ORM-HTML mapping app that was about 10% faster when I replaced all the strings with '' strings. This was on a slow machine with an early PHP, but little things like this can be very important. http://dev.stut.net/phpspeed/ You forgot to benchmark echo, everyone (me anyways) knows echo is faster than print. Why you ask? Because print returns a value, echo does not :) You *know* that for a fact do you? I've added a plain echo to complement the plain print, and in the 5 or 6 runs I've done print is always faster, but not by much. -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
On Thu, 2007-01-04 at 11:13 +, Stut wrote: Robert Cummings wrote: On Thu, 2007-01-04 at 10:15 +, Stut wrote: Gregory Beaver wrote: This is a good example of how the flexibility of PHP can bite you, but is also a good example of how bad coding adds both complexity and inefficiency to the resulting software. If f() is called often, there might be a noticeable speedup if it were replaced. I once had a complex database ORM-HTML mapping app that was about 10% faster when I replaced all the strings with '' strings. This was on a slow machine with an early PHP, but little things like this can be very important. http://dev.stut.net/phpspeed/ You forgot to benchmark echo, everyone (me anyways) knows echo is faster than print. Why you ask? Because print returns a value, echo does not :) You *know* that for a fact do you? I've added a plain echo to complement the plain print, and in the 5 or 6 runs I've done print is always faster, but not by much. Hmmm, something must have changed :) Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
# [EMAIL PROTECTED] / 2007-01-04 05:51:12 -0500:
On Thu, 2007-01-04 at 10:15 +, Stut wrote:
Gregory Beaver wrote:
This is a good example of how the flexibility of PHP can bite you,
but is also a good example of how bad coding adds both complexity and
inefficiency to the resulting software. If f() is called often,
there might be a noticeable speedup if it were replaced. I once had
a complex database ORM-HTML mapping app that was about 10% faster
when I replaced all the strings with '' strings. This was on a
slow machine with an early PHP, but little things like this can be
very important.
http://dev.stut.net/phpspeed/
You forgot to benchmark echo, everyone (me anyways) knows echo is faster
than print. Why you ask? Because print returns a value, echo does not :)
And printf() is faster than echo:
Using ?php echo $x; ?
Took 1.4402 seconds
ť Reveal output
Using ?php print $x; ?
Took 1.1628 seconds
ť Reveal output
Using ?php printf('%s', $x); ?
Took 0.8289 seconds
ť Reveal output
--
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
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
On Thu, 2007-01-04 at 12:29 +, Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2007-01-04 05:51:12 -0500:
On Thu, 2007-01-04 at 10:15 +, Stut wrote:
Gregory Beaver wrote:
This is a good example of how the flexibility of PHP can bite you,
but is also a good example of how bad coding adds both complexity and
inefficiency to the resulting software. If f() is called often,
there might be a noticeable speedup if it were replaced. I once had
a complex database ORM-HTML mapping app that was about 10% faster
when I replaced all the strings with '' strings. This was on a
slow machine with an early PHP, but little things like this can be
very important.
http://dev.stut.net/phpspeed/
You forgot to benchmark echo, everyone (me anyways) knows echo is faster
than print. Why you ask? Because print returns a value, echo does not :)
And printf() is faster than echo:
Using ?php echo $x; ?
Took 1.4402 seconds
ť Reveal output
Using ?php print $x; ?
Took 1.1628 seconds
ť Reveal output
Using ?php printf('%s', $x); ?
Took 0.8289 seconds
ť Reveal output
I call shenanigans! :B There's no way printf() can be faster than echo.
Echo isn't even a function.
Cheers,
Rob.
--
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`'
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
Stut wrote: Robert Cummings wrote: On Thu, 2007-01-04 at 10:15 +, Stut wrote: Gregory Beaver wrote: This is a good example of how the flexibility of PHP can bite you, but is also a good example of how bad coding adds both complexity and inefficiency to the resulting software. If f() is called often, there might be a noticeable speedup if it were replaced. I once had a complex database ORM-HTML mapping app that was about 10% faster when I replaced all the strings with '' strings. This was on a slow machine with an early PHP, but little things like this can be very important. http://dev.stut.net/phpspeed/ nice little overview. You forgot to benchmark echo, everyone (me anyways) knows echo is faster than print. Why you ask? Because print returns a value, echo does not :) You *know* that for a fact do you? I've added a plain echo to complement the plain print, and in the 5 or 6 runs I've done print is always faster, but not by much. out of interest, are you logging the result of each request? your probably getting quite a lot of hits to your phpspeed page right now - storing the results of everyone's requests is a nice way to grab extra/free data whilst you pick your nose ;-) -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
Jochem Maas wrote: out of interest, are you logging the result of each request? your probably getting quite a lot of hits to your phpspeed page right now - storing the results of everyone's requests is a nice way to grab extra/free data whilst you pick your nose ;-) I'm not at the moment. It's a good idea though, if I get some time over lunch I'll add it. I had an eerie feeling I was being watched. -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
On Thu, 2007-01-04 at 11:13 +, Stut wrote: Robert Cummings wrote: On Thu, 2007-01-04 at 10:15 +, Stut wrote: Gregory Beaver wrote: This is a good example of how the flexibility of PHP can bite you, but is also a good example of how bad coding adds both complexity and inefficiency to the resulting software. If f() is called often, there might be a noticeable speedup if it were replaced. I once had a complex database ORM-HTML mapping app that was about 10% faster when I replaced all the strings with '' strings. This was on a slow machine with an early PHP, but little things like this can be very important. http://dev.stut.net/phpspeed/ You forgot to benchmark echo, everyone (me anyways) knows echo is faster than print. Why you ask? Because print returns a value, echo does not :) You *know* that for a fact do you? I've added a plain echo to complement the plain print, and in the 5 or 6 runs I've done print is always faster, but not by much. Running from the shell over 100 million iterations and several times for print and echo, echo ekes out an advantage. What's interesting is the big difference in speed difference between php 4 and 5 for both echo and print. PHP5 reduces time by about 40%. Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
On Thu, 2007-01-04 at 10:54 +, Roman Neuhauser wrote: echo $blah . \n is *not* equivalent to printf(%s\n, $blah) H, could you explain to me how it is different? I would always use the former unless I specifically needed formatting provided by printf(), and since there no formatting in the above printf() the echo to the best of my knowledge is indeed equivalent. Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
# [EMAIL PROTECTED] / 2007-01-04 12:55:40 +0100: Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2007-01-04 11:38:58 +: Jochem Maas wrote: out of interest, are you logging the result of each request? your probably getting quite a lot of hits to your phpspeed page right now - storing the results of everyone's requests is a nice way to grab extra/free data whilst you pick your nose ;-) I'm not at the moment. It's a good idea though, if I get some time over lunch I'll add it. What data? the timing results. :-) The timing results carry no information since we don't know what other things the computer was doing while the script was running. How are you going to remove the effect of concurrent requests for the page from the numbers? why would you want to - it actually make for a more realistic test. No. -- 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
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
# [EMAIL PROTECTED] / 2007-01-04 11:38:58 +: Jochem Maas wrote: out of interest, are you logging the result of each request? your probably getting quite a lot of hits to your phpspeed page right now - storing the results of everyone's requests is a nice way to grab extra/free data whilst you pick your nose ;-) I'm not at the moment. It's a good idea though, if I get some time over lunch I'll add it. What data? How are you going to remove the effect of concurrent requests for the page from the numbers? The other mail I sent showing a run where printf() came out almost twice as fast as echo clearly shows that the numbers carry little information. All that I could gather from several runs was that *printf() is *slightly* slower than echo, and that the difference isn't large enough to justify ditching *printf(). I knew this before. -- 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
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2007-01-04 11:38:58 +: Jochem Maas wrote: out of interest, are you logging the result of each request? your probably getting quite a lot of hits to your phpspeed page right now - storing the results of everyone's requests is a nice way to grab extra/free data whilst you pick your nose ;-) I'm not at the moment. It's a good idea though, if I get some time over lunch I'll add it. What data? the timing results. :-) How are you going to remove the effect of concurrent requests for the page from the numbers? why would you want to - it actually make for a more realistic test. besides which it's not so much the real numbers that come out of any given request as the differences between the numbers produced by each test within a single request. my point is that if you gather enough raw numbers of a a long enough period of time then you will start to a see a realiable *trend* at the end of the day nothing is 100% when it comes to benchmarking - and even if you could make it so the real world has to many unknowns and mitigating factors as to make the benchmarks completely worthless (unless you selling something ;-) The other mail I sent showing a run where printf() came out almost twice as fast as echo clearly shows that the numbers carry little information. All that I could gather from several runs was that *printf() is *slightly* slower than echo, and that the difference isn't large enough to justify ditching *printf(). I knew this before. obviously coding preference and code maintainance weigh heavily (or should do so imho); your time is precious - hardware is cheap :-) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2007-01-04 12:55:40 +0100: Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2007-01-04 11:38:58 +: Jochem Maas wrote: out of interest, are you logging the result of each request? your probably getting quite a lot of hits to your phpspeed page right now - storing the results of everyone's requests is a nice way to grab extra/free data whilst you pick your nose ;-) I'm not at the moment. It's a good idea though, if I get some time over lunch I'll add it. What data? the timing results. :-) The timing results carry no information since we don't know what other things the computer was doing while the script was running. In a single request I would agree with you. But combining the results of all requests over a fairly lengthy period will provide useful results. I'm not gonna get a chance to do anything with it today. I'll have a look tomorrow. -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
# [EMAIL PROTECTED] / 2007-01-04 12:53:14 +: Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2007-01-04 12:55:40 +0100: Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2007-01-04 11:38:58 +: Jochem Maas wrote: out of interest, are you logging the result of each request? your probably getting quite a lot of hits to your phpspeed page right now - storing the results of everyone's requests is a nice way to grab extra/free data whilst you pick your nose ;-) I'm not at the moment. It's a good idea though, if I get some time over lunch I'll add it. What data? the timing results. :-) The timing results carry no information since we don't know what other things the computer was doing while the script was running. In a single request I would agree with you. But combining the results of all requests over a fairly lengthy period will provide useful results. I'm not gonna get a chance to do anything with it today. I'll have a look tomorrow. Do share your numbers. My wife does statistics for a living, let's see what she'll have to say. -- 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
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2007-01-04 12:55:40 +0100: Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2007-01-04 11:38:58 +: Jochem Maas wrote: out of interest, are you logging the result of each request? your probably getting quite a lot of hits to your phpspeed page right now - storing the results of everyone's requests is a nice way to grab extra/free data whilst you pick your nose ;-) I'm not at the moment. It's a good idea though, if I get some time over lunch I'll add it. What data? the timing results. :-) The timing results carry no information since we don't know what other things the computer was doing while the script was running. which is most likely the exact case in real world situations. How are you going to remove the effect of concurrent requests for the page from the numbers? why would you want to - it actually make for a more realistic test. No. I'll take that to mean all your work runs on servers that handle each request in series, one at a time, and does nothing else apart from run php_mod/phpcgi ( the webserver)? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2007-01-04 14:26:11 +0100: Roman Neuhauser wrote: How are you going to remove the effect of concurrent requests for the page from the numbers? why would you want to - it actually make for a more realistic test. No. I'll take that to mean all your work runs on servers that handle each request in series, one at a time, and does nothing else apart from run php_mod/phpcgi ( the webserver)? No. My work has nothing to do with internet or networking in general, consisting of a SAPI-neutral library and a command line tool. that does clarify your position somewhat. :-) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
On Thu, 2007-01-04 at 14:16 +, Roman Neuhauser wrote: I'm not gonna get a chance to do anything with it today. I'll have a look tomorrow. Do share your numbers. My wife does statistics for a living, let's see what she'll have to say. I'm not sure why you guys even bother to run a benchmark on a single function / semantic via the web when it's not web dependent. There's much less noise running via shell. Not to mention as a shell script it's much easier to use the system time command and millions of iterations to get a better idea of the exact time. Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
Robert Cummings wrote: On Thu, 2007-01-04 at 10:54 +, Roman Neuhauser wrote: echo $blah . \n is *not* equivalent to printf(%s\n, $blah) H, could you explain to me how it is different? I would always use the former unless I specifically needed formatting provided by printf(), and since there no formatting in the above printf() the echo to the best of my knowledge is indeed equivalent. Hi, It is exactly the same (elegantly proving my point, btw) Greg -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
Robert Cummings wrote: On Thu, 2007-01-04 at 14:16 +, Roman Neuhauser wrote: I'm not gonna get a chance to do anything with it today. I'll have a look tomorrow. Do share your numbers. My wife does statistics for a living, let's see what she'll have to say. I'm not sure why you guys even bother to run a benchmark on a single function / semantic via the web when it's not web dependent. There's much less noise running via shell. Not to mention as a shell script it's much easier to use the system time command and millions of iterations to get a better idea of the exact time. I was bored when I wrote it. Dunno what the other guys reasons are. -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
Stut wrote: Robert Cummings wrote: On Thu, 2007-01-04 at 14:16 +, Roman Neuhauser wrote: I'm not gonna get a chance to do anything with it today. I'll have a look tomorrow. Do share your numbers. My wife does statistics for a living, let's see what she'll have to say. I'm not sure why you guys even bother to run a benchmark on a single function / semantic via the web when it's not web dependent. There's much less noise running via shell. Not to mention as a shell script it's much easier to use the system time command and millions of iterations to get a better idea of the exact time. I was bored when I wrote it. Dunno what the other guys reasons are. the devil, idle hands, all that jazz ;-: -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
On Thu, 2007-01-04 at 15:34 +0100, Jochem Maas wrote: Stut wrote: Robert Cummings wrote: On Thu, 2007-01-04 at 14:16 +, Roman Neuhauser wrote: I'm not gonna get a chance to do anything with it today. I'll have a look tomorrow. Do share your numbers. My wife does statistics for a living, let's see what she'll have to say. I'm not sure why you guys even bother to run a benchmark on a single function / semantic via the web when it's not web dependent. There's much less noise running via shell. Not to mention as a shell script it's much easier to use the system time command and millions of iterations to get a better idea of the exact time. I was bored when I wrote it. Dunno what the other guys reasons are. the devil, idle hands, all that jazz ;-: I wondered how I was getting so much work done :) Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
# [EMAIL PROTECTED] / 2007-01-04 14:26:11 +0100: Roman Neuhauser wrote: How are you going to remove the effect of concurrent requests for the page from the numbers? why would you want to - it actually make for a more realistic test. No. I'll take that to mean all your work runs on servers that handle each request in series, one at a time, and does nothing else apart from run php_mod/phpcgi ( the webserver)? No. My work has nothing to do with internet or networking in general, consisting of a SAPI-neutral library and a command line tool. -- 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
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2007-01-04 12:53:14 +: Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2007-01-04 12:55:40 +0100: Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2007-01-04 11:38:58 +: Jochem Maas wrote: out of interest, are you logging the result of each request? your probably getting quite a lot of hits to your phpspeed page right now - storing the results of everyone's requests is a nice way to grab extra/free data whilst you pick your nose ;-) I'm not at the moment. It's a good idea though, if I get some time over lunch I'll add it. What data? the timing results. :-) The timing results carry no information since we don't know what other things the computer was doing while the script was running. In a single request I would agree with you. But combining the results of all requests over a fairly lengthy period will provide useful results. I'm not gonna get a chance to do anything with it today. I'll have a look tomorrow. Do share your numbers. My wife does statistics for a living, let's see what she'll have to say. statistics is not an exact science - other than in the regard that you can conclude from any set of numbers exactly whatever [the ] you want. we're not interested here in exact, hard facts when it comes to the end result because real world systems are much too unpredictable to make any concrete correlations between a 'prefect' benchmark and the performance of a given production system. what we are interested is the interpretation by many minds (that's us on this list in this case) of quantitative, empirical data in order to achieve a reasonable level of predictability with regard to the general performance of any given piece of [php] code (as compared with alternative means of getting the same result) within a real world system. I get the feeling you might be taking this thread a tad too personally Roman, an with regard to 'wives on this list' - only John Nichel's wife is fair game and then only at his discretion :-P (that's a reference to some thread way back when, just joking around as usual) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
On Wed, January 3, 2007 3:43 pm, Roman Neuhauser wrote:
function print_any($any){
[34 lines of a switch ellided]
}
Nice. Now I see how the dynamic nature of PHP boosts development. :)
It was intentionally excessive to prove a point.
And because copy/pasting the possible values from the manual was
easier than thinking. :-)
I know you have a smiley and all, but, really, it's a write-once
function, and it's guaranteed to work for PHP 3 through PHP 5, with
reasonable error-handling for PHP 6 and beyond.
gettype hasn't changed in a long time and is unlikely to change in
future versions.
That __toString magic didn't even exist in earlier versions, and has
already changed out from under you once, right?...
So which one really makes sense to use for robust code? :-)
[shrug]
So, actually, it's not about try/catch being Java, as try/catch did
not originate with Java, as it is about try/catch just not being
scalable to wide-spread development.
Can you qualify that statement? What things are impossible?
What's impossible is enforcing and checking that try/catch is used in
a consistent and coherent manner throughout a large body of code, from
multiple developers/sources, such that all the pieces of a large
software project are playing the same game plan.
try/catch *seems* really cool at first, as it localizes the
error-handling to the code doing the work, to some degree, while
allowing a natural semantic for dealing with the errors.
Once you have a non-trivial application, however, the try/catch that
fires, and the error being caught, may have little or nothing to do
with each other, as functions nested in methods wrapped around
functions with methods inside them going umpteen layers deep...
You end up catching somebody else's error and handling it, even though
what you THINK has gone wrong is not at all what actually went wrong,
because they didn't write a try/catch handler where they should have.
E.g.:
You write this nice little bit:
try {
$file = fopen(/some/path/or/other, 'r');
}
catch ($e){
//handle error from opening $file
}
Then, some day soon, somebody splices in this:
try {
if (something($whatever)){
$file = fopen(/some/path/or/other, 'r');
}
}
catch ($e){
//handle error from opening $file
}
Then later on after that (possibly weeks/months/years) some other
programmer (or yourself) changes the 'whatever' function to use
fopen() to open a file, but does NOT wrap that in a try/catch because
it's some silly little file that has to work
Well, then it doesn't work one day, for whatever reason, and your
catch handler detects a failure in 'fopen' but it's not the fopen you
think it is, it's the other 'fopen' buried deep in some other function
somewhere else that didn't get caught.
Sure, it's bad code -- But it's the kind of bad code that
naturally accumulates in a large long-lived project over the years,
rather than some glaring nasty code that you'll refuse to live with,
or fix, or will cause immediate problems in functionality.
At the other end of the telescope, you'll also end up, sooner or
later, with somebody 'catching' an error and doing something with it
that you really really really wish they didn't do -- But you have no
recourse, as their try/catch block is buried deep in the guts of code
you do not want to mess with.
At least, this has been my experience with try/catch.
YMMV.
--
Some people have a gift link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
On Thu, January 4, 2007 5:28 am, Robert Cummings wrote: [echo versus print] Hmmm, something must have changed :) print used to be different from echo. I think there is little or no difference any more. Depends on your PHP version, however. It was a gradual change, with at least 2 increments, from print the function to print the language construct, I think. You'll have to read source or at least changelogs to get details though, as I only noticed the changes as an observer, rather than following them closely. I've always just used echo, so never really cared about print one way or another. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
On Thu, January 4, 2007 6:49 am, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2007-01-04 11:38:58 +: Jochem Maas wrote: out of interest, are you logging the result of each request? your probably getting quite a lot of hits to your phpspeed page right now - storing the results of everyone's requests is a nice way to grab extra/free data whilst you pick your nose ;-) I'm not at the moment. It's a good idea though, if I get some time over lunch I'll add it. What data? How are you going to remove the effect of concurrent requests for the page from the numbers? The other mail I sent showing a run where printf() came out almost twice as fast as echo clearly shows that the numbers carry little information. All that I could gather from several runs was that *printf() is *slightly* slower than echo, and that the difference isn't large enough to justify ditching *printf(). I knew this before. I believe that there may be some constructs within printf() that could make it slower than just echo -- and possibly in some cases with no real difference in output. printf(%s, $foo) should not be THAT much slower than echo $foo, so unless you're in some kind of tight loop with a zillion of them, it won't matter. I'm always befuddled by people arguing about the performance of this or that when it's a NON-ISSUE for the context in question, 99.9% of the time. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
# [EMAIL PROTECTED] / 2007-01-04 16:34:46 -0600:
On Wed, January 3, 2007 3:43 pm, Roman Neuhauser wrote:
That __toString magic didn't even exist in earlier versions, and has
already changed out from under you once, right?...
The whole program depends on the syntax and semantics of PHP 5.1, and
the fact that something hasn't changed for a long time means nothing
in this language. :)
So which one really makes sense to use for robust code? :-)
[shrug]
The one that's easier to maintain: faster to read, simpler to grok.
What's impossible is enforcing and checking that try/catch is used in
a consistent and coherent manner throughout a large body of code, from
multiple developers/sources, such that all the pieces of a large
software project are playing the same game plan.
try/catch *seems* really cool at first, as it localizes the
error-handling to the code doing the work, to some degree, while
allowing a natural semantic for dealing with the errors.
Once you have a non-trivial application, however, the try/catch that
fires, and the error being caught, may have little or nothing to do
with each other, as functions nested in methods wrapped around
functions with methods inside them going umpteen layers deep...
You end up catching somebody else's error and handling it, even though
what you THINK has gone wrong is not at all what actually went wrong,
because they didn't write a try/catch handler where they should have.
Yeah, that can lead to unexpected behavior. It still helps prevent
crashes.
try {
if (something($whatever)){
$file = fopen(/some/path/or/other, 'r');
}
}
catch ($e){
//handle error from opening $file
}
Then later on after that (possibly weeks/months/years) some other
programmer (or yourself) changes the 'whatever' function to use
fopen() to open a file, but does NOT wrap that in a try/catch because
it's some silly little file that has to work
Ok, but what harm has been done? something() presumably did the fopen()
for a reason, and couldn't work without the file handle and couldn't
succeed anyway.
Sure, the program leaves the normal path at this moment unexpectedly,
and I can understand your frustration, but it has a bug, right? And
although the program contains a bug it hasn't crashed, it just entered
whatever orderly cleanup-and-exit path you had prepared.
If fopen() didn't throw and the programmer didn't check the return value
(catch the exception in your version), you'd be screwed not even knowing
it.
I think you brought a solid example of superiority of exceptions over
returning error codes.
--
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
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
On Thu, January 4, 2007 4:54 am, Roman Neuhauser wrote: echo $blah . \n is *not* equivalent to printf(%s\n, $blah) Mathematically-speaking, not only is it equivalent, it is equal. :-) I think... Okay, I'll turn that into a question: For what input of $blah do these output different strings? -- Some people have a gift link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
On Thu, January 4, 2007 6:17 pm, Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2007-01-04 16:34:46 -0600:
You end up catching somebody else's error and handling it, even
though
what you THINK has gone wrong is not at all what actually went
wrong,
because they didn't write a try/catch handler where they should
have.
Yeah, that can lead to unexpected behavior. It still helps prevent
crashes.
try {
if (something($whatever)){
$file = fopen(/some/path/or/other, 'r');
}
}
catch ($e){
//handle error from opening $file
}
Then later on after that (possibly weeks/months/years) some other
programmer (or yourself) changes the 'whatever' function to use
fopen() to open a file, but does NOT wrap that in a try/catch
because
it's some silly little file that has to work
Ok, but what harm has been done? something() presumably did the
fopen()
for a reason, and couldn't work without the file handle and couldn't
succeed anyway.
Sure, the program leaves the normal path at this moment unexpectedly,
and I can understand your frustration, but it has a bug, right? And
although the program contains a bug it hasn't crashed, it just entered
whatever orderly cleanup-and-exit path you had prepared.
If fopen() didn't throw and the programmer didn't check the return
value
(catch the exception in your version), you'd be screwed not even
knowing
it.
I think you brought a solid example of superiority of exceptions over
returning error codes.
over returning error codes and not DOING anything with them? Sure.
Over well-written code that does something with the returned error
codes? no. Just a stylistic difference really, if all developers
consistently did their error-checking, and did it fairly well.
Alas, they don't.
And, suppose it's NOT an fopen() that was the problem deep in the guts
of the other guy's code.
Now you are catching an error and you have NO IDEA what the [bleep] to
do with it.
At least with error code returns, you are USUALLY dealing with a
specific way to get those codes (in PHP, not C-style shell-style
pass-the-buck error code bubble-up).
And, of course, you just ignored the question of another catch block
doing something you wish it didn't do...
--
Some people have a gift link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
# [EMAIL PROTECTED] / 2007-01-04 18:45:07 -0600: On Thu, January 4, 2007 6:17 pm, Roman Neuhauser wrote: Ok, but what harm has been done? something() presumably did the fopen() for a reason, and couldn't work without the file handle and couldn't succeed anyway. Sure, the program leaves the normal path at this moment unexpectedly, and I can understand your frustration, but it has a bug, right? And although the program contains a bug it hasn't crashed, it just entered whatever orderly cleanup-and-exit path you had prepared. If fopen() didn't throw and the programmer didn't check the return value (catch the exception in your version), you'd be screwed not even knowing it. I think you brought a solid example of superiority of exceptions over returning error codes. over returning error codes and not DOING anything with them? Sure. Over well-written code that does something with the returned error codes? no. Just a stylistic difference really, if all developers consistently did their error-checking, and did it fairly well. Alas, they don't. That's exactly the point. Programmers don't check return values, programs have bugs. And, suppose it's NOT an fopen() that was the problem deep in the guts of the other guy's code. Now you are catching an error and you have NO IDEA what the [bleep] to do with it. If you really don't know what to do, then the right thing is probably an orderly exit of the application, no? At least with error code returns, you are USUALLY dealing with a specific way to get those codes (in PHP, not C-style shell-style pass-the-buck error code bubble-up). With error codes, you are USUALLY dealing with crashes and wrong behavior. Compiled programs segfault, programs in PHP produce unspecified numbers of E_NOTICE, E_WARNING, and quite easily drop dead with an E_FATAL before returning to where you'd be complaining that you don't know what to do with the error! And, of course, you just ignored the question of another catch block doing something you wish it didn't do... I don't know what that means. -- 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
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
# [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]
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:
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.
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.
--
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
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
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
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
# [EMAIL PROTECTED] / 2007-01-03 14:07:31 +0100:
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.
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
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2007-01-03 14:07:31 +0100:
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.
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
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
# [EMAIL PROTECTED] / 2007-01-03 16:43:14 +0100:
Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2007-01-03 14:07:31 +0100:
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.
Why is it awful coding? I have a piece of code where exactly this is
(was in 5.1) a perfectly reasonable thing to do (the example is
contrived to clearly demonstrate the behavior at hand). The output was
for informational purposes, and the Object #N presentation was
completely adequate even with its quirks.
BTW, would you share a version of f($any) that meets your definition of
good code?
function f($any)
{
printf(%s\n, $any);
}
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.
That's why I didn't ask *you*. ;)
--
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
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
# [EMAIL PROTECTED] / 2007-01-03 16:43:14 +0100:
Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2007-01-03 14:07:31 +0100:
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.
You don't, look at Python. Instead of warnings and fatal errors, good
for logging purposes at best, you get to choose how to handle the
problem.
What kind of dynamic typing are we talking about if
f($any)
{
printf(%s, $any);
}
is bad code?
If you dare to use dynamic features in PHP you're begging to have your
throat cut by some call to undefined method, or hop in to lala land with
an undefined member variable access warning... If problems with the
dynamic typing of PHP end in somewhat undynamic fatal errors, your
only choice is to have all paths in the program statically verified,
IOW, steer completely clear of the dynamic features. That'll be a
terribly tedious job.
You can do this in Python (completely safe and meaningful):
def f(any):
print %s % any
You can even call any method on any object safely:
def g(o):
o.f()
If o doesn't have a callable member called f, you'll get an exception
you can catch:
def g(o):
try:
o.f()
except AttributeError:
print stderr, oops!
The lack of global error handlers allows mixing of independently
developed software, that's quite dynamic.
If you believe that something like
f($any)
{
if (is_string($any)) {
printf(%s, $any);
} else if (...) {
...
}
}
is better than the single sprintf() version, we'll just have to agree to
disagree. Where's the dynamism again? You could write this in C++:
void f(any a)
{
cout a;
}
with less typing more dynamism than you get with PHP. And the resulting
binary won't crash at runtime.
--
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
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
On Wed, 2007-01-03 at 17:49 +, Roman Neuhauser wrote:
If you dare to use dynamic features in PHP you're begging to have your
throat cut by some call to undefined method, or hop in to lala land with
an undefined member variable access warning... If problems with the
dynamic typing of PHP end in somewhat undynamic fatal errors, your
only choice is to have all paths in the program statically verified,
IOW, steer completely clear of the dynamic features. That'll be a
terribly tedious job.
You can do this in Python (completely safe and meaningful):
def f(any):
print %s % any
You can even call any method on any object safely:
def g(o):
o.f()
If o doesn't have a callable member called f, you'll get an exception
you can catch:
def g(o):
try:
o.f()
except AttributeError:
print stderr, oops!
The lack of global error handlers allows mixing of independently
developed software, that's quite dynamic.
Not to get into this argument but the PHP equivalent is:
?php
if( method_exists( $o, 'f' ) )
{
$o.f();
}
else
{
fprintf( stderr, 'oops!' );
}
?
Cheers,
Rob.
--
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`'
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
# [EMAIL PROTECTED] / 2007-01-03 11:57:03 -0500: Not to get into this argument [...] Nah, just chattin'. -- 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
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
On Wed, 2007-01-03 at 11:57 -0500, Robert Cummings wrote:
On Wed, 2007-01-03 at 17:49 +, Roman Neuhauser wrote:
?php
if( method_exists( $o, 'f' ) )
{
$o.f();
That should have been $o-f() btw. Too much JavaScript lately :D
Cheers,
Rob.
--
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`'
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
On Wed, January 3, 2007 8:24 am, Roman Neuhauser wrote:
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?
Sure.
function f($any)
{
printf(%s\n, $any);
}
function print_any($any){
switch(gettype($any)){
case boolean: // (since PHP 4)
echo $any ? true\n : false\n;
break;
case integer:
case double: //aka float
case string:
echo $any\n;
break;
case array:
var_dump($any);
echo \n;
break;
case object:
//you could check for the method __toString() if you like.
var_dump($any);
echo \n;
break;
case resource: //(since PHP 4)
echo Internal PHP Resource: $any\n;
break;
case NULL: //(since PHP 4)
echo NULL\n:
break;
case user function: // (PHP 3 only, deprecated)
echo UPGRADE! Function: $any\n;
break;
case unknown type:
default:
echo unknown data type\n;
error_log(__FILE__ . : . __LINE__ . unknown data type.
Check gettype documentation);
break;
}
}
The problem with try/catch is that, as already noted in this thread,
as soon as you reach a certain level of complexity and a large enough
code-base, the whole house of cards comes tumbling down because one
developer somewhere isn't using the same semantics for errors as you
are. This can be as obvious as not using try/catch at all, to
something very subtle such as what to *DO* with the errors or what
kinds of errors to catch.
So, actually, it's not about try/catch being Java, as try/catch did
not originate with Java, as it is about try/catch just not being
scalable to wide-spread development.
--
Some people have a gift link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
# [EMAIL PROTECTED] / 2007-01-03 14:01:29 -0600:
On Wed, January 3, 2007 8:24 am, Roman Neuhauser wrote:
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?
Sure.
function f($any)
{
printf(%s\n, $any);
}
function print_any($any){
[34 lines of a switch ellided]
}
Nice. Now I see how the dynamic nature of PHP boosts development. :)
The problem with try/catch is that, as already noted in this thread,
as soon as you reach a certain level of complexity and a large enough
code-base, the whole house of cards comes tumbling down because one
developer somewhere isn't using the same semantics for errors as you
are.
Erm, no. The note I made earlier in this thread said that changing
semantics of unsuspecting programs by using a throwing error handler
would be disastrous, and that was after I discussed using such a
throwing handler *for better error handling*.
This can be as obvious as not using try/catch at all, to
something very subtle such as what to *DO* with the errors
Same kinds of things you do with errors in a procedural program.
or what kinds of errors to catch.
Those that you know how to handle, of course. Or was that a different
question?
So, actually, it's not about try/catch being Java, as try/catch did
not originate with Java, as it is about try/catch just not being
scalable to wide-spread development.
Can you qualify that statement? What things are impossible?
--
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
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
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]
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().
It's also an example of a former C coder's understanding of how to do
things in PHP. Not only is this extremely inefficient (a function call
is significant overhead in PHP) it is doubly inefficient through the
unnecessary use of printf(). printf() is best used when you are
modifying the display of the output, the %s modifier by itself is
pointless in PHP.
function f($any)
{
echo $any . \n;
}
This has no E_RECOVERABLE_ERROR possibility and is far more efficient.
Better yet, replace
f($blah)
with
echo $blah . \n
This is a good example of how the flexibility of PHP can bite you, but
is also a good example of how bad coding adds both complexity and
inefficiency to the resulting software. If f() is called often, there
might be a noticeable speedup if it were replaced. I once had a complex
database ORM-HTML mapping app that was about 10% faster when I replaced
all the strings with '' strings. This was on a slow machine with an
early PHP, but little things like this can be very important.
Greg
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2007-01-03 16:43:14 +0100:
Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2007-01-03 14:07:31 +0100:
BTW, would you share a version of f($any) that meets your definition of
good code?
I would suggest adding some sanity checking - as opposed to relying on
any kind of error trigger/trapping/catching mechanism.
the regard to the point of the possible/perceived cons of working with an
interpreted, dynamically typed language the post Gregory Beaver made make the
case much more clearly than I could have.
I'll leave this thread for what it is now, leave it to say that it's been
a very interesting discussion and I certainly appreciated your [Roman]
thoughtful examples arguments.
rgds,
Jochem
function f($any)
{
printf(%s\n, $any);
}
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.
That's why I didn't ask *you*. ;)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
Hi, 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 about a way to permit users to upgrade to PHP 5.2.0 without modify all theirs scripts. In fact, many users had just installed open sources scripts (forums, cms, ...), which make somes E_RECOVERABLE_ERROR. So, we can hide them by adding E_RECOVERABLE_ERROR to the errors mask of the php.ini but it's not solving the real problem. Is there a way ? a temporary method ? which permit to use php 5.2 without forcing customers to accept the new E_RECOVERABLE_ERROR. so a way providing a two time upgrade (option in php.ini ?) Thanks. Best regards, -- David -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0
David CHANIAL wrote: Hi, 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] about a way to permit users to upgrade to PHP 5.2.0 without modify all theirs scripts. In fact, many users had just installed open sources scripts (forums, cms, ...), which make somes E_RECOVERABLE_ERROR. So, we can hide them by adding E_RECOVERABLE_ERROR to the errors mask of the php.ini but it's not solving the real problem. masking the errors might be short term solution - better to not mask them but also setup php to log errors rather than display them (see the display_errors ini setting) and point your users to the error log. it may be possible to merrily ignore the E_RECOVERABLE_ERRORs but chances are they point to real problems in the code and they should be corrected. Is there a way ? a temporary method ? which permit to use php 5.2 without forcing customers to accept the new E_RECOVERABLE_ERROR. so a way providing a two time upgrade (option in php.ini ?) no there is not. sorry for the bad news. Thanks. Best regards, -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
