Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107609
MIME-Version: 1.0
References: <CAJkq-zzRaVYVvQ_pJbKu1vGNTQSTZ_pFF6yzhVrDF4N-M8NbiA@mail.gmail.com>
 <CALKiJKombs9+L9Sp0p4zDwbGb9+uYU7Rju2eAWXxktcagsz0iA@mail.gmail.com>
In-Reply-To: <CALKiJKombs9+L9Sp0p4zDwbGb9+uYU7Rju2eAWXxktcagsz0iA@mail.gmail.com>
Date: Mon, 21 Oct 2019 19:25:56 +0200
Message-ID: <CAH0Uv3FfJ=6LN=whewRs0WswxLXN6TSRXWyUaNYCwYsTp81d9A@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Reclassifying some PHP functions warning as exceptions
From: andreas@dqxtech.net (Andreas Hennings)

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 related 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 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]