Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87463
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.216 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXZCr42ny2DDE59g_tqCMoTJdwuhNLgvqDatm-WTh+35kg@mail.gmail.com>
References: <CALYT1Yo-ae+cemXaaXs5Jv5t2DSzdxdYuxuhEGbXyoo_863+bw@mail.gmail.com>
	<836BA21C-AE99-4E7B-AB06-EBC30E41BA0E@icicle.io>
	<CAKws9z2PQWT7rSsM5R9TD-O69Ovy7-eifAuF-S0BQhBh3z4h1w@mail.gmail.com>
	<0AD335F5-35F3-4D98-8F82-800A1EDF8FD8@icicle.io>
	<05f101d0c838$fcdab5e0$f69021a0$@belski.net>
	<CAKws9z0yjxWisObfQ323rk3fA78yqJtRG=6zYDvjuPHEKH4=ag@mail.gmail.com>
	<55B63FDF.6050100@gmail.com>
	<CAKws9z1nXmci53v+3xOnROo-t45hwc9QTzJgdACBgDoi1O7DnQ@mail.gmail.com>
	<55B66494.1020106@gmail.com>
	<CAKws9z3=xJi3MwEN6Qi7Xxaphr3KLXZcAwmiN-jq924iKUpN3w@mail.gmail.com>
	<55B6707A.3040405@gmail.com>
	<CAAyV7nFxJB79VtypdRUpc=diZL1HcQ_ACQ4mvE3fSb_x-9B-Vg@mail.gmail.com>
	<CAKws9z1OLJg4EVdh1GS1vnpEPy7mDJoaX_ZETtJ4v-VivCdQww@mail.gmail.com>
	<CANUQDChDbJfDLqagSmtVW4pKtau5zTmvvO9A4hFJpdJMj_i53g@mail.gmail.com>
	<CAKws9z3x-Cg4cGwrurHj6czvgY7=2JHpoXQnseSHxK8wBs56Zw@mail.gmail.com>
	<CAGa2bXaRGcC60ifxykb=Qox5VJVEPJ4X4BFTjXirk=A_Mgi_tQ@mail.gmail.com>
	<CANUQDChYke1sagpLHY=8xdft_LAQ1751=CmDzV4izzzmw4QiRQ@mail.gmail.com>
	<CAGa2bXYKBFQWfni5+gd8pL=AXN6=5DHyj+4_k0F7JVEEDD=ioQ@mail.gmail.com>
	<CANUQDCiY3WsecUx8h-5ZF-PF9=uhTB7=neRCXUbFL9JT8gA5-w@mail.gmail.com>
	<CAGa2bXZCr42ny2DDE59g_tqCMoTJdwuhNLgvqDatm-WTh+35kg@mail.gmail.com>
Date: Sat, 1 Aug 2015 00:20:57 +0200
Message-ID: <CANUQDCj9KbUMQcZGLYjCWSTo-O9rwpX3-KQR7xh2Vtmr186P-w@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Scott Arciszewski <scott@paragonie.com>, Rowan Collins <rowan.collins@gmail.com>, 
	Anthony Ferrara <ircmaxell@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec53f2e27e8a317051c333bd0
Subject: Re: [PHP-DEV] Core functions throwing exceptions in PHP7
From: me@kelunik.com (Niklas Keller)

--bcaec53f2e27e8a317051c333bd0
Content-Type: text/plain; charset=UTF-8

2015-07-31 23:36 GMT+02:00 Yasuo Ohgaki <yohgaki@ohgaki.net>:

> Hi Niklas,
>
> On Fri, Jul 31, 2015 at 7:20 PM, Niklas Keller <me@kelunik.com> wrote:
>
>> Using set_error_handler isn't handling errors gracefully. Well, it's
>> better than E_ERROR, but then libraries can't handle those errors
>> gracefully, because the user might override its error handler by setting an
>> own handler.
>
>
> Now I see what do you mean by "gracefully".
>
> TL;DR;
> It's app developer jobs to handle these fatal errors.
>

Nope.


> Most fatal errors shouldn't be recovered by library. e.g. Fallback to non
> CSPRNG when CSPRNG is not
> available.
>

They should totally be handled. You need to catch the error and throw a
defined exception, otherwise your public API will break if you choose to
use another internal implementation.
Additionally, you seem to assume that the library doesn't have to do things
like cleanups in such a case.

Regards, Niklas


> IMO, library authors do not have to worry about errors like session's
> E_RECOVERABLE_ERROR
> or CSPRNG not available. These are fatal errors by its nature and app
> developer or system administrator
> job to handle them.  We cannot blindly assume such fatal errors never
> happen in production apps, so we
> are better to give users a chance to return "Nice error page/message" when
> it happened.
>
> Anyway, we are better to move errors to exceptions at once and force "all"
> modules including 3rd party
> module to raise exceptions. i.e. Make php_error_docref() raise exceptions.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>

--bcaec53f2e27e8a317051c333bd0--