Re: [PHP] E_RECOVERABLE_ERROR - 5.1.6 to 5.2.0

On Thu, January 4, 2007 8:26 pm, Roman Neuhauser wrote:
# ceo@xxxxxxxxx / 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?
.