rfc:enhanced_error_handling

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:enhanced_error_handling [2010/01/10 16:07] – Differences Observerd and some renaming kampfcasparrfc:enhanced_error_handling [2017/09/22 13:28] (current) – external edit 127.0.0.1
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:  Hans-Peter Oeri <hp@oeri.ch>   * Author:  Hans-Peter Oeri <hp@oeri.ch>
-  * Status:  Drafting+  * Status:  Draft (Inactive)
   * First Published at: http://wiki.php.net/rfc/enhanced_error_handling   * First Published at: http://wiki.php.net/rfc/enhanced_error_handling
  
 ===== Introduction ===== ===== 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 etc. etc.+php_error(), zend_throw_exception(), 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 etc. etc.
  
 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//; +  * 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 ===== ===== 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 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. 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 "warnings" to the user - much like a message transport. As this is pre-existing, 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. 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 "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.+As of PHP 5.3, the concept of exception chaining has been introduced, whereas a "previous" exception 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 ====
rfc/enhanced_error_handling.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1

Page Tools