> I must have overlooked a detail here.
>
> According to https://github.com/tpunt/PHP7-Reference#throwable-interface
> there are Throwables called Error, as a separate designation from an
> exception. I didn't see this in the engine exceptions RFC, so I was
> unaware that was even a thing.
>
> In this case, yes, as long as you can wrap it in try/catch blocks,
> SecurityError which extends Error and/or implements Throwable is an
> excellent suggestion.
>
> Previously, I thought the suggestion was to stick to triggering errors
> (E_ERROR, E_RECOVERABLE_ERROR, etc.).
>
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises <https://paragonie.com>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
I believe some were suggesting triggering an E_ERROR, though most E_ERRORs in
the engine have been replaced with thrown Error exceptions, so I think using
E_ERROR in this case would be inappropriate.
As I suggested in my prior email, I think throwing an instance of Error would
be appropriate when the functions random_bytes() and random_int() fail.
There are several conditions that already cause the engine to throw an Error
(or subclass thereof):
(1)->method(); // Throws Error
declare(strict_types=1); array_map(1, 1); // Throws TypeError
require 'file-with-parse-error.php'; // Throws ParseError
eval("$a[ = 1;"); // Throws ParseError
1 << -1; // Throws ArithmeticError
intdiv(1, 0); // Throws DivisionByZeroError
1 % 0; // Throws DivisionByZeroError
Of particular interest in the above examples is intdiv(), an internal function
that can throw an instance of Error if the denominator is zero.
I propose that random_bytes() and random_int() should throw an instance of
Error if the parameters are not as expected or if generating a random number
fails. (To avoid further debate about a subclass, the function should throw
just a plain instance of Error, it can always be subclassed later without BC
concerns).
random_bytes() and random_int() failing closed is very important to prevent
misguided or lazy programmers from using false in place of a random value. A
return of false can easily be overlooked and unintentionally be cast to a zero
or empty string. A thrown instance of Error must be purposely caught and
ignored to produce the same behavior. As Larry pointed out, it is a very common
error for programmers to not do a strict check using === against false when
calling strpos().
Does anyone have a strong objection to the above proposal? If not, then I think
Sammy should update his PRs to throw an Error so they can be merged before the
next beta release.
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
