Xdebug 2.3: Improvements to Debugging
This is the fourth article in a series about new features in Xdebug 2.3, which was first released on February 22nd.
In this article we are looking at the improvements towards "remote" debugging.
The first improvement is the addition to view the values of user defined constants. In Xdebug this works by defining another context. Existing contexts are local variables, and super globals. In PhpStorm, they show up in the same "Variables" box:
Xdebug 2.3 defines a third context, "User defined constants". This new third context also shows up in PhpStorm's "Variables" box:
However, if you have lots of constants, that becomes annoying. Follow (or comment on) issue WI-21691 if you want to see this changed.
Other IDEs, such as Komodo, handle this by having a separate tab for constants:
It is actually clever enough to create a new tab for every new context that I come up with, as they haven't hard coded it.
Another new debugging feature is to be able to set an exception breakpoint on all exceptions, by using * as the exception name. Xdebug 2.3 also breaks on exception classes that are inherited from the ones you set a breakpoint on. With the following code:
<?php
class BaseException extends Exception {}
class ChildException extends BaseException {}
echo "start\n";
try
{
echo "first try\n";
throw new ChildException("No noes!");
}
catch ( ChildException $e )
{
echo "eat it\n";
}
echo "end\n";
?>
And the following exception breakpoints configured in PhpStorm:
Xdebug will now interrupt the script when it hits line 11 because an exception breakpoint for both BaseException (the parent of the exception that we are throwing) and * are configured.
The third feature that I would like to highlight is related to the additions to debugging exceptions. Xdebug now includes the exception's error code in the reply to the IDE. However, it does not seem that PhpStorm allows me to see which exception it broke on, and what its message and error code are.
For now, you will have to do with the raw XML result (after formatting):
-> run -i 6
<?xml version="1.0" encoding="iso-8859-1"?>
<response
xmlns="urn:debugger_protocol_v1"
xmlns:xdebug="http://xdebug.org/dbgp/xdebug"
command="run" transaction_id="6"
status="break" reason="ok"
>
<xdebug:message
filename="file:///tmp/xdebug-dbgp-test.php" lineno="28"
exception="FooBarException" code="43"
>
<![CDATA[this should still break]]>
</xdebug:message>
</response>
I have created issue WI-26880 in their issue tracker as a feature request.
And the last thing that has changed with debugging in Xdebug 2.3 is that now Xdebug will try to log when you do not have sufficient permissions to create a socket. For example when you have SELinux turned on but not properly configured. The new message is:
E: No permission connecting to client. This could be SELinux related. :-(
Other parts in this series:
Life Line
Stonechat on a Branch
This lovely male Stonechat perched up quite nicely for me on a branch at Staines Moor.
#photography #Birds #BirdPhotography #BirdsOfFediverse #NaturePhotography #wildlife
Merge branch 'v2022'
Update data to 2026f
Updated a building
Specify cycleways width
Survey if vacant places are still vacant
Specify whether places take fees to visit
Specify maximum allowed weights
Specify whether pedestrian crossings have islands
Specify whether kerbs have tactile paving
Determine the heights of kerbs
Specify street/place names to addresses
Survey housenumbers
Specify whether there are crossings at intersections of paths and roads
Specify whether traffic signals have sound signals
Specify whether traffic signals have tactile indications that it's safe to cross
Specify whether public transport stops have tactile paving
Specify whether public transport stops have bins
Specify path surfaces
Specify postbox royal cyphers
Survey postbox collection times
Specify maximum heights
Survey hairdresser's customers
Survey opening hours
Specify whether roads have lane markings


Shortlink
This article has a short URL available: https://drck.me/debugs23-bod