Yasuo Ohgaki wrote on 15/07/2015 12:20:
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.
This is simply incorrect, as demonstrated by conversion of existing
E_RECOVERABLE_ERROR states in the engine to Throwable, and nullified
RFCs which would have, had EngineExceptions not passed, convert
engine-issued E_ERRORs into E_RECOVERABLE_ERROR.
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.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
