+1 for Error On Jul 26, 2015 11:32 PM, "Aaron Piotrowski" <aa...@icicle.io> wrote:
> > > 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 > >
