Hi Rowan, On Wed, Jul 15, 2015 at 9:00 PM, Rowan Collins <rowan.coll...@gmail.com> wrote:
> If we are going to adopt exception for "functions", it would be better to >> have >> switch that convert all errors to exceptions. >> > > Strongly disagree. A runtime switch would be a horrible consistency > nightmare for userland, and many of the existing functions which > desperately need better error-handling (e.g. file I/O) don't issue an error > at the moment anyway. > > The only reason (and it's a massive reason, don't get me wrong) not to > start throwing exceptions all over the core is backwards compatibility. New > functions do not, by definition, have anything to be backwards compatible > with. > > So my suggestion is, to come up with some reasonable definition of "new > area of functionality" where we can do things in a way which everyone seems > to agree is basically better, i.e. throw Exceptions. > - The rule shouldn't apply for new variations or close cousins of existing > functions (e.g. the json_decode_to() that was briefly discussed should use > similar conventions to json_decode() if it were implemented), only in cases > like this where we're adding a new set of functions (the manual puts > random_bytes and random_int in their own "book": > http://php.net/manual/en/book.csprng.php). > - It also shouldn't be used for "routine" errors (like File Not Found), > only in place of conditions which can justify a fatal error - both for the > intuitive reason that an uncaught exception *is* a fatal error, and the > procedural reason that we may want to decide a policy for "routine" error > handling at a later date. > > At some point, we should revisit the general error-handling strategy of > both the language and the core library, but 7.0 having been somewhat > derailed (in my opinion) by the endless debates about scalar type hints, it > will have to wait until 8.0 before we can do anything radical to existing > functions. I prefer exception also. I agree with your discussion in general. The only difference is how PHP module functions should adopt exceptions. When PHP adopted naming standard, we didn't enforce new naming standard for all functions. As a result, we have "module_func_name" and "modulefuncname" still. The same thing will happen for exception/error. I would like to avoid such situation (at least for modules provided with PHP). i.e. One function raises exception, another raises error. I understand many of us dislike INI switch nor runtime switch that changes behavior. However, it's impossible to move to exception at once because we have no control for users' code including 3rd party modules. IMHO. Rather than adding exception adopted functions gradually, having the switch is better for in the long run. We may deprecate/remove the switch 10 years later or more. BTW, I'm thinking to have "ModulenameException"/"ModulenameFunctionException" or like rather than simply calling/converting errors to ErrorException when exception is enabled for functions. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
