rfc:enhanced_error_handling
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
rfc:enhanced_error_handling [2010/01/07 15:53] – Overhaul kampfcaspar | rfc:enhanced_error_handling [2014/04/08 22:56] – Inactive levim | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Request for Comments: Enhanced Error Handling ====== | ====== Request for Comments: Enhanced Error Handling ====== | ||
- | * Version: 0.1 | + | * Version: 0.5 |
- | * Date: | + | * Date: |
* Author: | * Author: | ||
- | * Status: | + | * Status: |
* First Published at: http:// | * First Published at: http:// | ||
===== Introduction ===== | ===== Introduction ===== | ||
- | php_error(), | + | php_error(), |
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. | 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 ===== | + | ==== 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. | 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/ | All other situations - like compilation problems, core errors in engine startup/ | ||
+ | |||
+ | ==== Differences Observed ==== | ||
+ | |||
+ | * Almost all error behaviours include a human readable //error message// and a machine readable //error code//; the ' | ||
+ | * Error codes - if used - do not follow any //common semantic rules// and are therefore not interpretable without knowing their source; even more, they might be defined externally (SQLSTATE or linked library). | ||
+ | * While traditionally error numbers have mostly been numeric, also // | ||
+ | * Error codes and - to a lesser extent - error messages are traditionally held in a special variable or place for later inspection. Information held there may be reset //upon request/new error// (errno in C, error_get_last in PHP) or with any subsequent // | ||
+ | * There may be just a //single holding space// for later inspection of error information (error_get_last), | ||
+ | * Functions not bailing out on error situations should return a //defined error value//. There is, however, a variety of defined error values - also dependent on the required valid return value range, which might include values that other functions use as error indicating value. | ||
+ | * Definition of error actions - as described in the introduction - is handled by //php.ini// or //object calls// or //not available// at all. None of it offers all options. | ||
+ | |||
+ | |||
+ | ===== Goals ===== | ||
+ | |||
+ | The goal would be to create a framework in which | ||
+ | * the //PHP user// decides, what kind of error reaction he wishes; that includes | ||
+ | * having a single //error call// that abstracts away from zend_errors/ | ||
+ | * a minimal // | ||
+ | * offers a //C-level API// for compiled extensions as well as a //PHP-level API// for frameworks in that language. | ||
+ | * can be used in //OOP// as well as //non-OOP// situations. | ||
+ | |||
+ | |||
+ | Such goals can only be achieved under the side condition of //complete backwards compatibility// | ||
+ | existing php and extensions must not be changed - all existing error behaviour must be mappable. | ||
===== Definitions ===== | ===== Definitions ===== | ||
- | ==== Error Behaviours | + | ==== Error Actions |
If an error condition is met, different types of reactions are possible: | If an error condition is met, different types of reactions are possible: | ||
Line 29: | Line 53: | ||
| Throw | same as Suppress, but throw an exception as well | | | Throw | same as Suppress, but throw an exception as well | | ||
- | The error behaviour | + | The error action |
+ | |||
+ | Noted-down error information, e.g. error code and message etc., would be available by a standardized API. | ||
+ | |||
+ | ==== Error Levels ==== | ||
- | Noted-down | + | Existing extensions use their error mechanisms not only to issue grave errors, but also to |
+ | transport mere " | ||
+ | both an //error// and a //warning// call should be supplied. The latter - ignoring all configuration - | ||
+ | choosing Suppress or Monitor as appropraiate action. | ||
==== Error Parameters ==== | ==== Error Parameters ==== | ||
Line 39: | Line 70: | ||
needs an exception class. | needs an exception class. | ||
- | Default values for those parameters should be configurable like the error behaviour. However, more specific | + | Default values for those parameters should be configurable like the error action. However, more specific |
values - like an BadFunctionCallException while testing parameters - have to be definable with the | values - like an BadFunctionCallException while testing parameters - have to be definable with the | ||
error call itself. | error call itself. | ||
- | |||
- | For extreme cases - like "one big exception block per script" | ||
- | should be enforcable by the user. | ||
==== Error Container Hierarchy ==== | ==== Error Container Hierarchy ==== | ||
Line 50: | Line 78: | ||
PHP lives of its extensibility. Different extensions currently show different | PHP lives of its extensibility. Different extensions currently show different | ||
default error behaviours. It goes without saying, that error behaviour must | default error behaviours. It goes without saying, that error behaviour must | ||
- | keep being configurable by extension. | + | keep being configurable |
- | As some extensions currently do, I propose to add a further | + | As some extensions currently do, I propose to add a layer of error |
- | configurability on object level (see e.g. PDO -> by PDO connection). They should | + | configurability on //object level// (see e.g. PDO -> by PDO connection). They should |
default to the extension' | default to the extension' | ||
+ | |||
+ | Without any hassle, // | ||
+ | a PDO connection could be inherited its PDOStatements. | ||
===== Special Cases ===== | ===== Special Cases ===== | ||
Line 62: | Line 93: | ||
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. | 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 " | + | As of PHP 5.3, the concept of exception chaining has been introduced, whereas a " |
==== Notices ==== | ==== Notices ==== | ||
Line 92: | Line 123: | ||
error_container *delegate; | error_container *delegate; | ||
- | | + | |
long | long | ||
zend_class_entry *exception; | zend_class_entry *exception; | ||
Line 108: | Line 139: | ||
Instead of writing explicit calls to zend_error or zend_exception_throw, | Instead of writing explicit calls to zend_error or zend_exception_throw, | ||
- | error behaviour. It does, however return the '' | + | error behaviour. It does, however return the //actual// action |
As errors might be suppressed, after the use of error_yell a defined return value should be returned to PHP. | As errors might be suppressed, after the use of error_yell a defined return value should be returned to PHP. | ||
Line 126: | Line 157: | ||
Apart from extensions in C, php code itself could use such unified error configuration as well. | 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 | + | Above mentioned error_yell function as well as utility functions to configure error actions |
read error information should be available. | read error information should be available. | ||
Line 135: | Line 166: | ||
class ErrorClass { | class ErrorClass { | ||
function __construct( $parent_container ) | function __construct( $parent_container ) | ||
- | function | + | function |
- | function | + | function |
function yellError(...); | function yellError(...); | ||
function getLastError(); | function getLastError(); | ||
Line 157: | Line 188: | ||
==== Extensions ==== | ==== Extensions ==== | ||
- | Extensions can keep backwards compatibility, | + | Extensions can keep backwards compatibility, |
==== Core ==== | ==== Core ==== | ||
Line 175: | Line 206: | ||
| 2009-12-28 | | 2009-12-28 | ||
| 2010-01-07 | | 2010-01-07 | ||
+ | | 2010-01-10 |
rfc/enhanced_error_handling.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1