[prev in list] [next in list] [prev in thread] [next in thread] 

List:       php-internals
Subject:    Re: [PHP-DEV] Core functions throwing exceptions in PHP7
From:       Yasuo Ohgaki <yohgaki () ohgaki ! net>
Date:       2015-07-31 23:43:19
Message-ID: CAGa2bXZ6fdcz+wWyXkkJxn7Vu5G=e8cyxr-tqize_XiS7ZK+Sw () mail ! gmail ! com
[Download RAW message or body]


Hi Niklas,

On Sat, Aug 1, 2015 at 8:27 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> 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.
>>
>
> My thought is based on Design by Contract (Contract programming).
> When parameter or environment does not satisfy contract, contract error
> should be
> resulted in program/process termination.
>
> Fixing inappropriate parameter or environment is not library/framework
> author's
> responsibility, but the developer's. i.e.
> Caller(function/programmer/system admin)
> has the responsibility that satisfies parameter/environment requirement.
> If
> requirement is not met, it's perfectly OK for library/framework to raise
> fatal
> errors/exceptions. e.g. "You need PHP 5.6 or greater" error.
>

I'll be more specific for "CSPRNG not available" error.

If a author would like to handle the error and fallback to non crypt safe
RNG,
he/she should detect environment and execute alternative code for the
environment.

Catching exception and fallback to non crypt safe RNG is not optimal way
for handling unsatisfactory environment. IMHO. If we need function that
checks
environment, we are better to provide one rather than let users to use
exception.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net


[prev in list] [next in list] [prev in thread] [next in thread]