On 24.07.2009, at 16:06, Ben Scholzen 'DASPRiD' wrote:
-----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
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
