rfc:enhanced_error_handling

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

rfc:enhanced_error_handling [2010/01/08 21:11]
127.0.0.1 external edit
rfc:enhanced_error_handling [2017/09/22 13:28]
Line 1: Line 1:
-====== Request for Comments: Enhanced Error Handling ====== 
-  * Version: 0.4 
-  * Date:    2010-01-07 
-  * Author: ​ Hans-Peter Oeri <​hp@oeri.ch>​ 
-  * Status: ​ Drafting 
-  * First Published at: http://​wiki.php.net/​rfc/​enhanced_error_handling 
- 
-===== Introduction ===== 
- 
-php_error(),​ zend_throw_extension(),​ the @-operator... PHP and/or the Zend Engine respectively offer a variety of error issuance and handling mechanisms. There is, however, no encompassing concepts: Core functions only issue php_errors (suppressable),​ intl 1.0.3 by default suppresses all errors but can activate php_errors, pdo however has a flag to define error behaviour that allows exceptions - but limits php_error to E_WARNING. Furthermore,​ each extension has a different way of changing its error behaviour. 
- 
-I think that error behaviour has to be in the hands of the user (php coder). Different users have different preferences - and prefer different behaviour in different situations. 
- 
-===== Scope ===== 
- 
-Error conditions are encountered in a variety of places and cases. This RFC only covers error conditions in a running script, e.g. a file was not found. 
- 
-All other situations - like compilation problems, core errors in engine startup/​shutdown - are out of scope. 
- 
-===== Definitions ===== 
- 
-==== Error Behaviours ==== 
- 
-If an error condition is met, different types of reactions are possible: 
-^ Name               ^ Description ​                             ^ 
-| Suppress ​          | Note down error and return an //error value//, e.g. false/NULL | 
-| Monitor ​           | same as Suppress, but let a php monitor know - independent of error handling taken by user code| 
-| Error              | same as Suppress, but issue a php_error as well | 
-| Throw              | same as Suppress, but throw an exception as well | 
- 
-The error behaviour should be configurable by the user. An extension should not differ from the user's wishes, except in absolutely extraordinary circumstances. 
- 
-Noted-down error information,​ e.g. error code and message etc., should be available by a standardized API. 
- 
-==== Error Parameters ==== 
- 
-Different behaviours, ask for different additional parameters: ​ 
-zend_error needs an E_* value to distinguish warnings and errors and throwing an exception 
-needs an exception class. 
- 
-Default values for those parameters should be configurable like the error behaviour. However, more specific 
-values - like an BadFunctionCallException while testing parameters - have to be definable with the 
-error call itself. 
- 
-For extreme cases - like "one big exception block per script"​ - the default parameters 
-should be enforcable by the user. 
- 
-==== Error Container Hierarchy ==== 
- 
-PHP lives of its extensibility. Different extensions currently show different 
-default error behaviours. It goes without saying, that error behaviour must 
-keep being configurable by extension. 
- 
-As some extensions currently do, I propose to add a further layer of error 
-configurability on object level (see e.g. PDO -> by PDO connection). They should 
-default to the extension'​s behaviour, but be configurable differently. 
- 
-===== Special Cases ===== 
- 
-==== Enforced Exception class ==== 
- 
-A lower hierarchy level could enforce the use of a specific exception class, e.g. PersonalIntlExceptionClass() for all of intl.so. While forcing such a common class does ease catching, some information a more specific class could provide is lost. 
- 
-As of PHP 5.3, the concept of exception chaining has been introduced, whereas a "​previous"​ extension can be attached. In order to keep the previously lost information,​ the concrete exception class given upon issuing an error should be chained to the enforced class. 
- 
-==== Notices ==== 
- 
-Notices are issued en masse all over PHP - even for plain language constructs like array access. They are regularly ignored on production systems and seldomly indicate errors. I like to compare them to warnings of a compiler, indicating that something //could// go wrong here (php does issue them at runtime, not compile-time). 
- 
-Whereas an user could decide to downgrade every error to a notice in this concept, actual notices should be issued the same way as before. 
- 
-==== @-Operator ==== 
- 
-The @ operator does suppress error issuance for the evaluation of the expression it is prepended to. It does so - currently - completely for php_error()s,​ not however for exceptions. 
- 
-If possible, the operator should be limited to errors in the execution of scripts but "​silence"​ thrown exceptions as well (like a "per object"​ Suppress above). It's functionality should be prohibited, if a certain behaviour is enforced. 
- 
-===== C API ===== 
- 
-The following does not represent compilable code. 
- 
-==== Error Container ==== 
- 
-The levels mentioned above would need a common container structure to hold error 
-configuration as well as "last error" information. The same construct can be hold 
-by extensions as well as objects. 
- 
-<code c> 
-  struct error_container { 
-    char *name; ​                        // identification,​ e.g. extension name 
-    error_container *parent; ​           // hierarchy: inherit parent'​s configuration 
-    error_container *delegate; ​         // hierarchy: "​last"​ error is in a child from this one 
- 
-    error_behaviour ​ behaviour; ​        // error behaviour for this container 
-    long             ​level; ​            // default E_* 
-    zend_class_entry *exception; ​       // default exception class 
- 
-    error_incident incident; ​           // last error'​s information on this container'​s level 
-  } 
-</​code>​ 
- 
-==== Error Function ==== 
- 
-<code c> 
-  error_behaviour error_yell( error_container *container, long level, char *exception, long code, char *msg ); 
-  error_behaviour error_yellf( error_container *container, long level, char *exception, long code, char *format, ... ); 
-</​code>​ 
- 
-Instead of writing explicit calls to zend_error or zend_exception_throw,​ this call abstracts away the 
-error behaviour. It does, however return the ''​actual''​ behaviour initiated. 
- 
-As errors might be suppressed, after the use of error_yell a defined return value should be returned to PHP. 
-One //cannot// be sure that the engine will branch away into an error or exception handler. 
- 
-==== Utility functions === 
- 
-Apart from the error issuing function, several utility functions are needed, e.g.: 
-  * Creation/​Destruction of error containers 
-  * Setting/​Resetting error behaviour of containers 
-  * Reading error incidents 
-  * Clearing error incidents 
- 
-The corresponding API depends too much on implementation detais to discuss those here. 
- 
-===== PHP API ===== 
- 
-Apart from extensions in C, php code itself could use such unified error configuration as well. 
-Above mentioned error_yell function as well as utility functions to configure error behaviour and 
-read error information should be available. 
- 
-A standard ErrorClass - implementing an object 
-level error container plus standardized methods to access it - should be available: 
- 
-<code php> 
-  class ErrorClass { 
-    function __construct( $parent_container ) 
-    function setErrorBehaviour(...);​ 
-    function resetErrorBehaviour();​ 
-    function yellError(...);​ 
-    function getLastError();​ 
-  } 
-</​code>​ 
- 
-Of course, the internal ErrorClass could be used as base class for 
-extension classes as well. 
- 
-Error containers would be identified by: 
-  * NULL: global/​highest hierarchy 
-  * string: extension-level container (e.g. in a hash) 
-  * ErrorClass: object-level container 
- 
-In order to allow PHP frameworks to depend on an "​extension level" container, 
-such a string-identified container should be creatable on user level. 
- 
-===== Backwards Compatibility ===== 
- 
-==== Extensions ==== 
- 
-Extensions can keep backwards compatibility,​ if their current default behaviour is mapped to the above-mentioned extension level. Even special cases should be representable with the mentioned behaviours, parameters and enforcement. 
- 
-==== Core ==== 
- 
-The core should probably only be touched if this proposal (or something analogous) is included in it... 
- 
-===== Course of Action and Patch ===== 
- 
-  - Development:​ https://​saintcyr.oeri.ch/​trac/​php-error/​ 
-  - Given enough feedback and operating experience, the enhanced error handling could be bundled in an "error extension"​ 
-  - Other extensions could use the "error extension"​ 
- 
-===== Changelog ===== 
- 
-^ Date        ^ Author ​     ^ Message ​                ^ 
-| 2009-12-27 ​ | kampfcaspar | Created Initial Version | 
-| 2009-12-28 ​ | kampfcaspar | Added draft API         | 
-| 2010-01-07 ​ | kampfcaspar | Overhaul ​               | 
  
rfc/enhanced_error_handling.txt · Last modified: 2017/09/22 13:28 (external edit)