Xdebug 2.3: Munging errors
This is the third article in a series about new features in Xdebug 2.3, which was first released on February 22nd.
One of the first features I added to Xdebug was the interception of error messages, so that it was possible to shows stack traces when an error occurred. Xdebug 2.3 has a few additional settings to control the behaviour of interception.
First, we have the new xdebug.halt_level. This setting allows you to tell Xdebug to convert certain warnings into fatal errors. Due to the way how PHP works, you can currently only do this for E_WARNING, E_NOTICE, E_USER_WARNING, and E_USER_NOTICE.
Setting xdebug.halt_level to E_NOTICE | E_USER_NOTICE will make the following script not show Hi!:
<?php
ini_set('xdebug.halt_level', E_USER_NOTICE | E_NOTICE);
trigger_error("Testing");
echo "Hi!\n";
?>
Instead, it will show the call stack, and then abort the script:
Notice: Testing in - on line 3
Call Stack:
0.0082 258480 1. {main}() -:0
0.0085 259400 2. trigger_error() -:3
This feature was requested by Rob Allen, who also wrote about it.
The second related improvement is the addition of the xdebug.force_display_errors and xdebug.force_error_reporting settings. These php.ini only settings can be used to override PHP's display_errors and error_reporting settings. This is typically useful in a legacy code base where developers tried to be clever about not showing warnings, or for example turning of notices that now hamper developer - or upgrade efforts.
Take the following script:
<?php
ini_set("display_errors", 0);
trigger_error("two");
?>
When you run this with just php thescript.php, the output will be nothing (because you are hiding errors). Running the example script with php -d
xdebug.force_display_errors=1 thescript.php, the output becomes:
Notice: two in /tmp/thescript.php on line 3
Call Stack:
0.0002 261072 1. {main}() /tmp/thescript.php:0
0.0002 261944 2. trigger_error() /tmp/thescript.php:3
The related setting xdebug.force_error_reporting acts at a bit mask to force certain errors to be shown. Even with error_reporting set to 0, the following script run with php -d xdebug.force_error_reporting
/tmp/otherscript.php will still show the errors:
<?php
ini_set("error_reporting", E_ERROR | E_WARNING | E_USER_WARNING);
trigger_error("two", E_USER_NOTICE);
?>
With as output:
Notice: two in /tmp/otherscript.php on line 3
Call Stack:
0.0002 261432 1. {main}() /tmp/otherscript.php:0
0.0003 262352 2. trigger_error() /tmp/otherscript.php:3
Other parts in this series:
Life Line
Updated 3 restaurants
I walked 3.1km in 29m25s
I walked 4.4km in 45m01s
I walked 5.4km in 55m28s
Updated a restaurant; Confirmed a hotel
I walked 6.3km in 1h12m59s
Paraphrasing opening keynote speaker at ConFoo: "Should we go back to the waterfall method of writing massive specs upfront to feed to AI coding agents?"
I walked 1.6km in 17m29s
I walked 2.1km in 17m44s
Updated a pub
I walked 2.6km in 26m41s
Merged pull request #1065
Comparison whether class is userland or internal used the wrong macro
PHP 8.6: zend_enum.h now mixes code with declarations
PHP 8.6: Argument names are now stored as zend_strings
Updated a bench and a waste_basket
I walked 8.3km in 1h25m37s
Created a recycling
I walked 10.5km in 1h46m57s
An interesting journey in story form, showing how English changed over time.
https://www.deadlanguagesociety.com/p/how-far-back-in-time-understand-english
A much better writer than I is summing up perfectly why I have such disdain for Generative AI/LLMs.
https://jonn.substack.com/p/so-why-do-i-feel-so-angry-about-this
Created a waste_basket; Updated a waste_basket; Deleted a bench
Created a bench; Updated 7 benches and a gate; Deleted 2 benches and a gate
Created 10 benches and 2 waste_baskets; Updated an information


Shortlink
This article has a short URL available: https://drck.me/errors23-bns