> I agree with the distinction described by Nikita.
> There are definitely cases where a special return value is still the
> best option.
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
}
```
Instead of:
```
if (! mkdir('somedir')) {
// now what? did it fail because the directory already exists? or
because of any other reason?
// sure, you can now perform a file_exists() or is_dir(), but:
// 1. it's not atomic
// 2. this second call may fail as well (especially if it's an I/O
error), and now what?
// 3. if this is something like an I/O exception or a permission
exception, you really should log it;
// will you replicate the logging logic in each and every of your
filesystem function calls?
}
```
Last but not least, a blind mkdir() in a quick-and-dirty script will stop
execution if it fails, which in the vast majority of the cases is what you
want.
— Benjamin
On Mon, 21 Oct 2019 at 19:26, Andreas Hennings <andr...@dqxtech.net> wrote:
> I agree with the distinction described by Nikita.
> There are definitely cases where a special return value is still the
> best option.
>
> In addition I would say in some cases it can be useful to have both
> versions available: One that returns FALSE or NULL, another that
> throws an exception.
> This is for cases where it is up to the calling code whether a failure
> is considered "exceptional" or not, or whether the calling code wants
> to check the error in place or have it bubble up the call stack.
>
> Whether something is exceptional can be a matter of expectation, and
> previous knowledge within the calling code.
>
> Take e.g. the reflection API:
> - If we call "new ReflectionClass(self::class)", we assume that the
> class exists. If it does not, this would warrant a runtime exception.
> - If we already checked "class_exists($class)" before, then it makes
> sense for "new ReflectionClass($class)" to throw an exception. We
> would even want a runtime exception.
> - If we receive an arbitrary string that matches a class name regex,
> we would like to have a ReflectionClass::createOrNull($class), which
> would NOT throw an exception, but return NULL if the class does not
> exist.
>
> If we provide two variations, they should definitely live in different
> functions / methods, instead of e.g. having a parameter to determine
> the failure behavior.
> Having two separate methods/functions allows better code verification
> by the IDE, and avoids false inspection warnings for "unhandled
> exception".
>
> Considering the BC impact, I think that providing an alternative
> method/function will be the best we can do in most cases.
>
> -- Andreas
>
> On Mon, 21 Oct 2019 at 18:03, Rowan Tommins <rowan.coll...@gmail.com>
> wrote:
> >
> > Hi David,
> >
> > Firstly, I agree with Nikita's general rule of which Warnings should be
> > promoted and which need deeper thought.
> >
> > I would like to challenge one assertion in your e-mail, which is related
> to
> > that thought process:
> >
> >
> > On Mon, 21 Oct 2019 at 14:52, David Negrier <
> d.negr...@thecodingmachine.com>
> > wrote:
> >
> > > We would be happy to promote more warnings to exceptions as those:
> > > - are more predictable
> > > - can be more easily caught / handled
> > >
> >
> >
> > I have always thought, and continue to think, that converting all
> Warnings
> > (and Notices) to Exceptions is inappropriate, because Exceptions have
> some
> > very specific behaviours, which are not always desirable:
> >
> > - They immediately jump control out of the current frame of execution.
> > Unless you put a separate "try-catch" around every line, there is no
> > "acknowledge and run next line".
> > - Their default behaviour if not handled is to completely terminate
> > whatever is happening, right up to showing a blank white screen.
> >
> > There is no general way to know whether the result of aborting execution
> > completely is better or worse than carrying on with unexpected values.
> In a
> > program that's not expecting it, either one could lead to data loss or
> > corruption.
> >
> > There are definitely places where a Warning can reasonably be converted
> to
> > an Exception; but I don't think this should be done as some kind of bulk
> > change. Each Warning we promote should have at least one person answer
> the
> > question "is it likely that terminating processing when this happens at
> > run-time will be better than flagging a Warning and returning a defined
> > value?"
> >
> > Regards,
> > --
> > Rowan Tommins
> > [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
