For the method of the class as an error handler, the `set_error_handler` function may return a `callable`:
a) a string
b) a Closure
c) an indexed array (with the name of the class or an instance of the class in the first element, and the name of the method in the second one)
However, it is not limited to just "an indexed array with the class and method name".
I suggest removing the mention of the array as a return value, otherwise we will have to list every possible type of callable value :)
- Indicate that E_STRICT is deprecated as of PHP 8.4.0
- explain the case where E_RECOVERABLE_ERROR can happen
- E_USER_ERROR should not be used any more.
- Rewording which removes personalization
Co-authored-by: Christoph M. Becker <cmbecker69@gmx.de>
* trigger-error.xml: add the `literal` tag for the E_USER_*
* trigger-error.xml: change the family of constants syntax
Co-authored-by: Peter Cowburn <petercowburn@gmail.com>
---------
Co-authored-by: Peter Cowburn <petercowburn@gmail.com>
Remove IDs from error constants on the core constants page.
Standardize constant IDs on the error handling constant page.
---------
Co-authored-by: haszi <haszika80@gmail.com>
- UPGRADING says that the error_reporting (ie. value returned by error_reporting() or ini_get('error_reporting ')) is changed, not the severity value passed to the handler.
- UPGRADING says that the error_reporting() == 0 should be replaced with !(error_reporting() & $err_no) in code, not the return with return false. So there is currenctly no way how to detect @ operator.
- "Prior to PHP 8.0.0, the value of the severity passed to the custom error handler was always 0" - no true
- "return false; // Silenced" - not true, if the function returns false then the normal error handler continues, so it is not "silenced".
(partially reverts "Cleanup and update docs related to @ operator" commit 12b1d4704ea448b55ec155619be1e50c0e67e9f9.)
Co-authored-by: George Peter Banyard <girgias@php.net>
Co-authored-by: Larry Garfield <larry@garfieldtech.com>
First, the $callback is a callable, and users are supposed to either
know what that means, or look it up elsewhere in the documentation, so
there is no need to explain it here again, and let it rot again.
Second, there is no need anymore to document pre PHP 7.0.0 behavior.
* Documenting the changes to syslog.filter
https://github.com/php/php-src/pull/4265 restored the previous handling of multi-line log messages by adding `syslog.filter=raw`.
* Highlight the fact that line splitting is happening in all of the three original modes, but not in "raw".
* Add "raw" to syslog section of 7.3 migration guide
Closes GH-589.