Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107610
MIME-Version: 1.0
References: <CAJkq-zzRaVYVvQ_pJbKu1vGNTQSTZ_pFF6yzhVrDF4N-M8NbiA@mail.gmail.com>
 <CALKiJKombs9+L9Sp0p4zDwbGb9+uYU7Rju2eAWXxktcagsz0iA@mail.gmail.com> <CAH0Uv3FfJ=6LN=whewRs0WswxLXN6TSRXWyUaNYCwYsTp81d9A@mail.gmail.com>
In-Reply-To: <CAH0Uv3FfJ=6LN=whewRs0WswxLXN6TSRXWyUaNYCwYsTp81d9A@mail.gmail.com>
Date: Mon, 21 Oct 2019 19:45:13 +0200
Message-ID: <CAG9XoMRT=iMKuxDCJW=zWbzm10BFFoKMLVx3aVrUGYbzs1KdMg@mail.gmail.com>
To: Andreas Hennings <andreas@dqxtech.net>
Cc: Rowan Tommins <rowan.collins@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a48f3205956f3f0b"
Subject: Re: [PHP-DEV] Reclassifying some PHP functions warning as exceptions
From: benjamin.morel@gmail.com (Benjamin Morel)

--000000000000a48f3205956f3f0b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>  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.

=E2=80=94 Benjamin



On Mon, 21 Oct 2019 at 19:26, Andreas Hennings <andreas@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.collins@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 relate=
d
> to
> > that thought process:
> >
> >
> > On Mon, 21 Oct 2019 at 14:52, David Negrier <
> d.negrier@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 executio=
n
> > 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 bul=
k
> > 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
>
>

--000000000000a48f3205956f3f0b--