On 21/10/2019 18:45, Benjamin Morel wrote:
I personally like exceptions in all cases, as they allow for
fine-grained error handling, for example:
```
try {
mkdir('somedir');
} catch (FileExistsException $e) {
// only catch *this* exception, which my program expects,
// let any other exception (say a PermissionException or a generic
IoException) bubble up!
// this *is* what you want: it will be caught by your top-level
exception handler which will log it to inform you that something is
wrong with your system
}
```
I think this argument is something of a logical fallacy: just because
exceptions are (or can be) more fine-grained than the current return
value, that doesn't mean they're the best tool for the job.
If I'm remembering it correctly, an example is the old PEAR
error-handling model, where rather than false, functions returned a
PEAR_Error object. This could be just as fine-grained (using sub-classes
or error code constants) as an exception, but without the additional
behaviour of blowing through the stack.
In some cases, you can go one step further, and have a "result" object,
with methods like isSuccessful(), getErrorCode(), and getOutput().
Importantly, this can and should be different for different functions.
In a previous message you wrote this, which I think mischaracterizes /
misunderstands previous discussions:
To play the devil's advocate, however, IIRC some discussions in the past
mentioned that the BC breakage that comes with it is such an issue that it
would be preferable to create a brand new API rather than attempting to fix
the existing one.
Nobody ever jumped in to propose such an API, though :-(
It's not that we need "a brand new API", singular, it's that some of the
more complex sets of functions should be redesigned, with error handling
considered as part of each design.
So, a new file-handling API could provide a much richer set of error
codes for its equivalent of fopen(), which might or might not involve
exceptions. It might instead have a file handle object which could
represent closed and errored handles, so that attempting to open a file
would always give the same result type, but would have information about
what failed.
Meanwhile, if we were to design a new string API to make things more
consistent, and perhaps introduce better Unicode support where relevant,
that would be a good chance to throw exceptions for truly exceptional
cases. However, we might also include more forgiving variants of
functions, for "best effort" processing of user input (like iconv's
//TRANSLIT and //IGNORE modes).
On the other hand, there are some errors where the answer to the
question "would it be better to halt processing than continue in an
unknown state?" is "yes", so it's reasonable to introduce an exception,
even though existing programs aren't expecting it. But again, this
should be considered for every case, not as a general rule that all
Warnings should be promoted.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
