Differences

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

--- rfc:enhanced_error_handling [2010/01/10 16:07] – Differences Observerd and some renaming kampfcaspar
+++ rfc:enhanced_error_handling [2011/04/06 10:59] – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
 ====== Request for Comments: Enhanced Error Handling ======
-  * Version: 0.4
+  * Version: 0.5
-  * Date:    2010-01-07
+  * Date:    2010-01-10
   * Author:  Hans-Peter Oeri <hp@oeri.ch>
   * Status:  Drafting
@@ Line 20: / Line 20: @@
 ==== Differences Observed ====
- * Almost all error behaviours include a human readable //error message// and a machine readable //error code//;
+  * Almost all error behaviours include a human readable //error message// and a machine readable //error code//; the 'original' zend_error however, does not define error codes, but far less granular //error types// (which are nevertheless named errno in parts of the docs, e.g. set_error_handler).
-   the 'original' zend_error however, does not define error codes, but far less granular //error types// (which
+  * 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 //alphanumeric// variants exist (SQLSTATE).
- * 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 //successful action/call// (PDO, intl).
-   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), a a //compartementalized// holding space for independent error information (PDO vs. PDOStatement) or even a //hierarchical// one, which combines the earlier two (intl).
- * While traditionally error numbers have mostly been numeric, also //alphanumeric// variants exist (SQLSTATE).
+  * 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 //successful action/call// (PDO, intl).
- * There may be just a single holding space for later inspection of error information (error_get_last), a
-   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 =====
@@ Line 42: / Line 33: @@
 The goal would be to create a framework in which
   * the //PHP user// decides, what kind of error reaction he wishes; that includes
-  * having an "error call" that abstracts away from zend_errors/exceptions and
+  * having a single //error call// that abstracts away from zend_errors/exceptions and
-  * a minimal inheritance of error behaviours, such that different extensions and/or resource objects might be configured to react differently.
+  * a minimal //inheritance of error behaviours//, such that different extensions and/or resource objects might be configured to react differently.
-  * 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.
@@ Line 69: / Line 61: @@
 Existing extensions use their error mechanisms not only to issue grave errors, but also to
 transport mere "warnings" to the user - much like a message transport. As this is pre-existing,
-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.

Differences

Page Tools