Re: Core functions throwing exceptions in PHP7

> 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