Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
rfc:engine_exceptions [2013/12/07 15:42] – nikic | rfc:engine_exceptions [2013/12/10 13:52] – Fix numbers (this is about engine, but I've been using total counts) nikic |
---|
==== Not all errors converted ==== | ==== Not all errors converted ==== |
| |
PHP currently (master on 2013-10-24) contains the following number of fatal-y errors: | The Zend Engine currently (master on 2013-12-10) contains the following number of fatal-y errors: |
| |
<code> | <code> |
E_ERROR: 439 (note: not counting 538 occurrences in zend_vm_execute.h) | E_ERROR: 183 (note: not counting 538 occurrences in zend_vm_execute.h) |
E_CORE_ERROR: 14 | E_CORE_ERROR: 12 |
E_COMPILE_ERROR: 145 | E_COMPILE_ERROR: 151 |
E_PARSE: 1 | E_PARSE: 1 |
E_RECOVERABLE_ERROR: 21 | E_RECOVERABLE_ERROR: 14 |
</code> | </code> |
| |
The patch attached to the RFC currently (as of 2013-10-24) removes 70 ''E_ERROR''s and 11 ''E_RECOVERABLE_ERROR''s. While I hope to port more errors to exceptions before the patch is merged, the process is rather time consuming and I will not be able to convert all errors or even most of them. (Note: The number of occurrences in the source code says rather little about what percentage of "actually thrown" errors this constitutes.) | The count was obtained using ''git grep "error[^(]*(E_ERROR_TYPE" Zend | wc -l'' and as such may not be totally accurate, but should be a good approximation. |
| |
Some errors are easy to change to exceptions, others are more complicated. Some are nigh impossible, like the memory limit or execution time limit errors. The ''E_CORE_ERROR'' type can't be converted to use exceptions because it occurs during startup (at least if used correctly). ''E_COMPILE_ERROR'' (and ''E_PARSE'') currently also can't be converted to exceptions, due to concerns regarding global state modifications. | The patch attached to the RFC currently (as of 2013-10-24) removes 70 ''E_ERROR''s and 11 ''E_RECOVERABLE_ERROR''s. While I hope to port more errors to exceptions before the patch is merged, the process is rather time consuming and I will not be able to convert all errors. (Note: The number of occurrences in the source code says rather little about what percentage of "actually thrown" errors this constitutes.) |
| |
| Some errors are easy to change to exceptions, others are more complicated. Some are impossible, like the memory limit or execution time limit errors. The ''E_CORE_ERROR'' type can't be converted to use exceptions because it occurs during startup (at least if used correctly). ''E_COMPILE_ERROR'' (and ''E_PARSE'') currently also can't be converted to exceptions, due to concerns regarding global state modifications. |
| |
Converting most existing errors will take some time and in the meantime we'll be in a situation where some part of the errors were converted to exceptions but another part stays fatal. From a user perspective it may not be immediately clear when one is used over the other. | Converting most existing errors will take some time and in the meantime we'll be in a situation where some part of the errors were converted to exceptions but another part stays fatal. From a user perspective it may not be immediately clear when one is used over the other. |
===== Backwards compatibility ===== | ===== Backwards compatibility ===== |
| |
The ''E_FATAL'' portion of this proposal does not break backwards compatibility: All code that was previously working, will continue to work. The change only relaxes error conditions, which is a change we do not regard as breaking BC. | The ''E_ERROR'' portion of this proposal does not break backwards compatibility: All code that was previously working, will continue to work. The change only relaxes error conditions, which is generally not regarded as breaking BC. |
| |
The ''E_RECOVERABLE_FATAL'' part of the proposal may introduce a minor BC break, because it will no longer allow to silently ignore recoverable errors with a custom error handler. As this point is somewhat controversial I'll have a separate voting option for this. | The ''E_RECOVERABLE_ERROR'' part of the proposal may introduce a minor BC break, because it will no longer allow to silently ignore recoverable errors with a custom error handler. As this point is somewhat controversial I'll have a separate voting option for this. |
| |
===== Patch ===== | ===== Patch ===== |