>
> 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.
Sure, you can do without exceptions. I think what you're suggesting is
similar to Go's error handling. But PHP at some point decided in favour of
exceptions, so it would be logical to pursue in that direction.
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.
I would classify most, if not all, filesystem-related functions as mostly
"yes, do stop execution by default when something fails". So this is, as
well, in favour of exceptions.
To take the mkdir() example, the only reasonable failure reason I can think
of that would not justify throwing an exception, is when the directory
already exists.
So I would be OK with this:
mkdir(): bool; // true if successful, false if the target directory already
exists
This is, IMO, the only time we can safely proceed while ignoring the
outcome of the operation, as the filesystem is in the same state whether or
not the function succeeded (the directory exists). All other outcomes are,
IMO, exceptional situations, and throwing an exception is a safe way to
guarantee that execution will *not* continue after such an error.
Handling each and every error manually by using the return value requires a
lot of discipline, which could be a very steep learning curve for PHP
developers used to a fast prototyping language. And if people don't
strictly follow the rules, you're opening the door to a whole lot potential
bugs in codebases. And, you miss the ability of automatic error reporting
for uncaught errors, that you get almost for free with exceptions and a
single try/catch at the top level.
— Benjamin
On Mon, 21 Oct 2019 at 20:46, Rowan Tommins <rowan.coll...@gmail.com> wrote:
> 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
>
>
