rfc:stackable_error_handler

Differences

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

Link to this comparison view

Next revision		Previous revision
rfc:stackable_error_handler [2013/03/19 23:19] – created tyraelrfc:stackable_error_handler [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 9: Line 9:
 ===== Introduction ===== ===== Introduction =====
  
-This RFC tries to address the couple of feedback and possible shortcomings of the current error handler infrastructure, introducing a stackable error handler infrastructure, which can be used to extend or replace the default error handler using a stackable API where multiple error handlers can co-exist and only care about their own errors.+This RFC tries to address the couple of feedback and possible shortcomings of the current error handler infrastructure, via introducing a stackable error handler infrastructure(similar to the current spl_autoload one), which can be used to extend or replace the default error handler using a stackable API where multiple error handlers can co-exist and only care about their own errors.
  
 ===== Proposal ===== ===== Proposal =====
  
-All the features and examples of the proposal.+There would be a built-in error handler set, which implements the current behavior: 
 +- log the errors based on the config (error_reporting, log_error, error_log, etc.) 
 +- display the errors based on the config. 
 +- provides the $php_errormsg based on the config 
 +- this handler is defined for E_ALL 
 + 
 +When you call set_error_handler using the old signature the the error handler will replace/shadow any other error handler set via the old signature and they will always come after the built-in handler but before any handler added with the new stackable signature. 
 +For example: 
 +1. built-in E_ALL 
 + 
 +set_error_handler(function($errno, $errstr, $errfile, $errline, $errcontext){/* do something here */}, E_WARNING) 
 +1. built-in E_ALL 
 +2. old-style E_WARNING 
 + 
 +set_error_handler(function($errno, $errstr, $errfile, $errline, $errcontext){/* do something else here */}, E_NOTICE) 
 +1. built-in E_ALL 
 +2. old-style #2 E_NOTICE 
 +  
 + 
 +The new stackable error handling would only generate and pass the error to the chain of handlers if there is at least one error handler set for that particular error type.
  
-To [[http://news.php.net/php.internals/66051|paraphrase Zeev Suraski]], explain hows the proposal brings substantial value to be considered 
-for inclusion in one of the world's most popular programming languages. 
  
-Remember that the RFC contents should be easily reusable in the PHP Documentation. 
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
  
Line 25: Line 41:
 ===== Proposed PHP Version(s) ===== ===== Proposed PHP Version(s) =====
  
-List the proposed PHP versions that the feature will be included in.  Use relative versions such as "next PHP 5.x" or "next PHP 5.x.y".+PHP 5.6 (or next major, if we happen to release a major version after 5.5).
  
 ===== SAPIs Impacted ===== ===== SAPIs Impacted =====
  
-Describe the impact to CLI, Development web server, embedded PHP etc. +TODO
- +
-===== Impact to Existing Extensions ===== +
- +
-Will existing extensions be affected?+
  
 ===== New Constants ===== ===== New Constants =====
  
-Describe any new constants so they can be accurately and comprehensively explained in the PHP documentation.+TODO
  
 ===== php.ini Defaults ===== ===== php.ini Defaults =====
  
-If there are any php.ini settings then list: +TODO
-  * hardcoded default values +
-  * php.ini-development values +
-  * php.ini-production values+
  
 ===== Open Issues ===== ===== Open Issues =====
  
-Make sure there are no open issues when the vote starts!+TODO
  
 ===== Unaffected PHP Functionality ===== ===== Unaffected PHP Functionality =====
  
-List existing areas/features of PHP that will not be changed by the RFC. +TODO
- +
-This helps avoid any ambiguity, shows that you have thought deeply about the RFC's impact, and helps reduces mail list noise.+
  
 ===== Future Scope ===== ===== Future Scope =====
  
-This sections details areas where the feature might be improved in future, but that are not currently proposed in this RFC.+TODO
  
 ===== Proposed Voting Choices ===== ===== Proposed Voting Choices =====
  
-Include these so readers know where you are heading and can discuss the proposed voting options.+TODO
  
 ===== Patches and Tests ===== ===== Patches and Tests =====
  
-Links to any external patches and tests go here. +TODO
- +
-If there is no patch, make it clear who will create a patch, or whether a volunteer to help with implementation is needed. +
- +
-Make it clear if the patch is intended to be the final patch, or is just a prototype.+
  
 ===== References ===== ===== References =====
  
-Links to external references, discussions or RFCs+TODO
  
 ===== Rejected Features ===== ===== Rejected Features =====
  
-Keep this updated with features that were discussed on the mail lists.+TODO
rfc/stackable_error_handler.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1

Page Tools