RFC: Replacing errors with Exceptions

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kalle Sommer Nielsen wrote:

Then ZF should provide an error handler that can be called inside the
user's error handler or simply choose to not use error handlers if
the
user have a custom error handler. I can't really see why the whole
language should change into using exceptions by default because of
something like this?

This second suggested solution doesn't change the current behaviour at
all, just adds an additional one, which under usual circumstances will
never appear.

Again, say for example, you have the following code:

---

$fp = @fopen(...);
if (!$fp) {
// !some! error occured, handle it
}

---

I already described the problems with this in the RFC, e.g. you don't
know, which error occurded, just that fopen failed. What a library
currently would have to do is:

---

function exception_error_handler($errno, $errstr, $errfile,
$errline ) {
throw new ErrorException($errstr, 0, $errno, $errfile, $errline);
}
set_error_handler('exception_error_handler');

try {
$fp = fopen(…);
} catch (ErrorException $e) {
// Handle the exception
}

restore_error_handler();

---

One could surely do that, yet it is not only unneccesary much
additional
code, but also introduces overhead by setting and restoring the error
handler again and again.

Well this RFC suggests using Exceptions as a solution to a well known
problem:
In many places you cannot really handle different error conditions
well, because you cannot differentiate between different error
conditions (did that include fail because of a parse error or because
the file is missing?) or because you are passing data to a function
who's job is to validate and handle the data (simplexml example).

Currently the only solution is to enable track errors and the shut up
operator. Obviously that sucks.

Generally we have decided to leave Exceptions out of core with a few
"exceptions":

1. errors in the constructor will throw an exception
2. extensions may choose to offer an Exception mode (see PDO)

I never understood why we did 1), if a constructor can fail, then a
factory should be used instead. But oh well. With 2) you are obviously
also opening a pandoras box, that is similar to using a global error
handler that turns all Notices, Warnings etc as Exception: you can
easily break code that calls various libraries .. take for example
passing in a PDO instance to one library which expects the normal
error mode and another one that enables the Exception mode. For the
most part however we can conclude that most libraries enable the
Exception mode in PDO and I think you will be hard pressed to find any
PDO code example that doesn't assume that the Exception mode is enabled.

So does that mean its time to open the flood gates? Contrary to what
the RFC states, Exceptions are not the one error handling mechanism to
rule them all. They should be used for exceptional cases, but for the
most part functions/methods do fine with just returning false. Thats
all people need to know most of the time.

The issue is when there isn't just one possible error condition but
many and as a result you want to do different things based on which
ever error condition occurred. So lets take the include example.
Obviously when using include, you accept the case that the file is
missing (is not readable .. not quite the same, but probably the same
for the purpose of this example), otherwise require would have been
used. So returning false in that case makes sense. However and here we
do not have an answer yet, what should be returned when the file
exists but has a parse error? This I would call an exceptional case,
but are these cases sufficiently relevant so that we should force
Exceptions upon our general userbase?

One alternative approach would be to ensure that there are simply
proper validation functions, that take the guess work out of the error
condition. Like for ages people have been asking to make file_exists()
able to work with the include path. In the same vain, a method for
validating an xml file could be provided. The issue is here of course
that in both of these examples, doing the validation incurs
significant overhead (more so in the xml case), so doing the
validation beforehand would adversely affect performance (nevermind
the possibility of race conditions further complicating things). So
one approach would be to use the shut up operator and only call the
validation method afterwards to determine the exact cause of the issue.

Anyways, just pondering .. I do not really have a good solution, just
trying to define the problem at hand a bit more and the some of
options on the table.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

On Fri, Jul 24, 2009 at 6:29 PM, Hannes
Magnussonhannes.magnusson@gmail.com wrote:

To you both, this is especially, for library code like Zend Framework.
The library cannot expect the user to have the error handle set, so it
would have to replace the error handler before every line which it wants
to try {} and reset it after the catch. This is not really a clean
solution, at it can occur pretty often.

Why do you have to replace it?

because in case of a library, there is a "third-party" called "user".
User might have his own opinion on error-handlers. And then, there's
even worse case, when there are 2 or three libraries mixed in the
single project

No. The RFC says it should throw Exception. There is no need for other
error handlers in that case.

If you want multiple error handlers then create RFC for error handler stacking.

-Hannes

On Fri, Jul 24, 2009 at 6:29 PM, Hannes
Magnussonhannes.magnusson@gmail.com wrote:

On Fri, Jul 24, 2009 at 15:43, Ben Scholzen
'DASPRiD'mail@dasprids.de wrote:

To you both, this is especially, for library code like Zend
Framework.
The library cannot expect the user to have the error handle set, so
it
would have to replace the error handler before every line which it
wants
to try {} and reset it after the catch. This is not really a clean
solution, at it can occur pretty often.

Why do you have to replace it?

because in case of a library, there is a "third-party" called "user".
User might have his own opinion on error-handlers. And then, there's
even worse case, when there are 2 or three libraries mixed in the
single project

Construct your error-handler to "stack" nicely and throw or
trigger_error whatever would have happened without it.

Then you need not unset/reset the silly thing.

--
Some people ask for gifts here.
I just want you to buy an Indie CD for yourself:
http://cdbaby.com/search/from/lynch

Sorry for top post, on my android. I disagree that php has perl phobia, but
I agree that a alternative to errors needs to be made. Your example is nice
but might have some tricky implementation details if php continued to throw
errors when it didn't detect $!. I.E. fopen(...) or throw new
CustomException($!); when custom exception writes to a log file that also
writes to $! Perhaps for file not found, For example, does the first fopen
throw the error or supress it as the user likely wanted. However it becomes
a moot point if errors are still thrown.

I agree, however there are certain aspects of PHP's errors that leave a lot
to be desired. For instance, a failed fopen or a failed socket will often
result in an uncatchable warning from php. Sure, you can add a @ to the line
but that's slow and doesn't tell you anything about what happened.

I've been saying for years that PHP needs to get over its perl phobia and
implement something like $!

fopen("file", "r") or throw new Exception("Error: ". $!);

Wouldn't that be nice?

On Jul 24, 2009, at 10:51 AM, Brian Moon wrote: > On 7/24/09 6:43 AM, Ben
Scholzen 'DASPRiD' wrot...

Matt Wilson wrote:

I agree, however there are certain aspects of PHP's errors that leave a
lot to be desired. For instance, a failed fopen or a failed socket will
often result in an uncatchable warning from php. Sure, you can add a @
to the line but that's slow and doesn't tell you anything about what
happened.

I've been saying for years that PHP needs to get over its perl phobia
and implement something like $!

fopen("file", "r") or throw new Exception("Error: ". $!);

Wouldn't that be nice?

I don't see the big difference between that and:

if(!fopen("file", "r")) throw new Exception();

and error_get_last() gives you the type, error message, line number, and
filename which you can access in your catch block. Presumably you still
want to log these which you get for free so no need for the @.

-Rasmus

I agree, however there are certain aspects of PHP's errors that leave
a lot to be desired. For instance, a failed fopen or a failed socket
will often result in an uncatchable warning from php. Sure, you can
add a @ to the line but that's slow and doesn't tell you anything
about what happened.

I've been saying for years that PHP needs to get over its perl phobia
and implement something like $!

fopen("file", "r") or throw new Exception("Error: ". $!);

Wouldn't that be nice?

No, it wouldn't.

wtf is $! supposed to mean?!

I don't want to know, actually.

If I wanted to use a language that looks like a cat died on my
keyboard, I'd just switch to perl.

--
Some people ask for gifts here.
I just want you to buy an Indie CD for yourself:
http://cdbaby.com/search/from/lynch

Hannes Magnusson wrote:

However, now that it's come up, I'm wondering what the costs/risks are
of setting libxml_use_internal_errors() on by default?

I don't think thats a good idea.
People are used to getting a warning when stuff fails, and suppressing
them all of the sudden is not cool and people will waste a good chunk
of time figuring out what is wrong with the script they are developing
and eventually find out libxml_use_internal_errors() is enabled by
default and they'll start flaming the list about how much we all suck.

Observing the thread, I totally agree to that. In my case I've "been
there, done that" and although I flamed at the beginning why I can't
catch the error properly (until I found the said function :) ), you can
bring the counter example too: give no libxml_use_internal_errors() and
throwing an exception instead, you don't have to worry about some
special function to flip error handling. You just know how to cope with
Exceptions, not some esoteric function to be called to get some
information out.

• Markus