Hi Rowan, On Wed, Jul 15, 2015 at 7:57 PM, Rowan Collins <rowan.coll...@gmail.com> wrote:
> Sammy Kaye Powers wrote on 14/07/2015 22:04: > >> Since the core functions in PHP don't throw Exceptions, there is debate on >> whether or not this change should be implemented. Some say the CSPRNG's >> should get a special pass since they will be relied on for cryptography. >> If >> we can't throw Exceptions, there were suggestions of raising a fatal error >> if the RNG fails. >> > > Given that the *engine itself* now throws exceptions, and we have bundled > extensions which throw exceptions, the blanket ban on exceptions "in core > functions" seems increasingly out-dated. This particular function is in > ext/standard, which is about as "core" as you can get, but it is a brand > new function with no BC considerations and an explicit mandate to be as > secure as possible. > > To me, using an exception here makes perfect sense, but I'm not sure how > to formulate a policy that allows that without opening the floodgates too > quickly. I'm also a big fan of proper exception hierarchies - I've seen so > many times that you should never *catch* the base Exception class, so > *throwing* a base Exception seems very wrong to me. As I wrote earlier, I prefer exceptions rather than errors. Engine exception is a little different. The main motivation for engine exception is to give a chance to users for graceful program termination. Functions can achieve the objective by E_RECOVERABLE_ERROR mostly. I don't want to see one function raise exception and the other raise error. It's "should be avoided inconsistency". IMHO. If we are going to adopt exception for "functions", it would be better to have switch that convert all errors to exceptions. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
