On Mon, Jul 27, 2015 at 10:27 AM, Rowan Collins <rowan.coll...@gmail.com> wrote: > Scott Arciszewski wrote on 27/07/2015 07:57: >> >> My only concern is that, we have a fixed timetable for the 7.0.0 >> release. It's certainly a good idea to develop a cogent strategy >> before moving forward, but I worry that bikeshedding will get involved >> and we won't make the deadline. >> >> I propose that, if a better strategy cannot be presented in time for >> RC1, consistency should take a back seat to security. Fail hard, throw >> an Error, deal with the details later. > > > I think taking on board Anatol's concerns about proper planning and > consistency, and yours about short timescales, the reasonable solution is to > create as small a possibility for future BC as possible, while maintaining > the "fail hard" policy. > > My suggestion would therefore be to raise an E_ERROR for this case in 7.0. > Unlike an E_RECOVERABLE_ERROR or any kind of Throwable, there is no way that > code can be written to explicitly handle that case, it will simply halt > execution. As such, there are no limits to what we can introduce later, > other than that unmodified code should continue to fail hard. > > This buys us time to put together a cogent policy for what if any built-in > functions can make use of Throwables in the 7.x release series, with a > likely result of throwing some class of Error for this function in 7.1. > > Regards, > -- > Rowan Collins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
The problem with fatal errors is that "This function can fail irrecoverably outside of your control" isn't going to encourage adoption. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
