rfc:enhanced_error_handling
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:enhanced_error_handling [2010/01/10 16:07] – Differences Observerd and some renaming kampfcaspar | rfc:enhanced_error_handling [2012/08/03 18:23] – I'm pretty sure that those extension-s should be exception-s. tyrael | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Request for Comments: Enhanced Error Handling ====== | ====== Request for Comments: Enhanced Error Handling ====== | ||
- | * Version: 0.4 | + | * Version: 0.5 |
- | * Date: 2010-01-07 | + | * Date: 2010-01-10 |
* Author: | * Author: | ||
* Status: | * Status: | ||
Line 8: | Line 8: | ||
===== 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. | ||
Line 20: | Line 20: | ||
==== Differences Observed ==== | ==== 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). |
- | are nevertheless named errno in parts of the docs, e.g. set_error_handler). | + | * While traditionally error numbers have mostly been numeric, also // |
- | * Error codes - if used - do not follow any common semantic rules and are therefore not interpretable without knowing | + | * 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 // |
- | their source; even more, they might be defined externally (SQLSTATE or linked library). | + | * There may be just a //single holding space// for later inspection of error information (error_get_last), |
- | * While traditionally error numbers have mostly been numeric, also // | + | * 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. |
- | * Error codes and - to a lesser extent - error messages are traditionally held in a special variable or place | + | * 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. |
- | 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), | + | |
- | a compartementalized holding space for independent error information (PDO vs. PDOStatement) | + | |
- | or even a hierarchical one, which combines the earlier two (intl). | + | |
- | * 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 ===== | ===== Goals ===== | ||
Line 42: | Line 33: | ||
The goal would be to create a framework in which | The goal would be to create a framework in which | ||
* the //PHP user// decides, what kind of error reaction he wishes; that includes | * the //PHP user// decides, what kind of error reaction he wishes; that includes | ||
- | * having | + | * having |
- | * a minimal inheritance of error behaviours, such that different extensions and/or resource objects might be configured to react differently. | + | * a minimal |
- | * offers a C-level API for compiled extensions as well as a PHP-level API for frameworks in that language. | + | * 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. | + | * 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. Default behaviour of | + | Such goals can only be achieved under the side condition of //complete backwards compatibility//. Default behaviour of |
existing php and extensions must not be changed - all existing error behaviour must be mappable. | existing php and extensions must not be changed - all existing error behaviour must be mappable. | ||
Line 69: | Line 61: | ||
Existing extensions use their error mechanisms not only to issue grave errors, but also to | Existing extensions use their error mechanisms not only to issue grave errors, but also to | ||
transport mere " | transport mere " | ||
- | both an //error and a //warning call should be supplied. The latter - ignoring all configuration - | + | both an //error// and a //warning// call should be supplied. The latter - ignoring all configuration - |
choosing Suppress or Monitor as appropraiate action. | choosing Suppress or Monitor as appropraiate action. | ||
Line 101: | 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 ==== |
rfc/enhanced_error_handling.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1