2

I know with Xdebug you can change your xdebug.collect_params settings, so that the error messages include more information about the parameters used in the calls. (There's a nice explaination about it here)

However, the string representations of my objects are very large and unreadable.

large and unreadable object representations

I already have some good toString implementations which just returns a unique id, so it would be really nice if I could let xdebug use __toString() instead of a full serialisation.

Is this (or any other customisation of the parameter formatting) possible?

I guess in theory I could try implementing custom representations through __sleep() but I actually need the default serialisation mechanisms to save objects across requests.

Flion
  • 10,468
  • 13
  • 48
  • 68
  • 1
    Sidenote: in php 5.6 the [`__debugInfo`](http://php.net/manual/en/language.oop5.magic.php#language.oop5.magic.debuginfo) method has been added. I don't really know but if xdebug uses `var_dump()` then you could move your `__toString()` logic to `__debugInfo()`. – Carlos Campderrós Feb 27 '15 at 07:21
  • yes, seems this is exactly the solution. Support for __debugInfo is implemented in the latest version of xdebug. Now I just need to wait for a WAMP update with PHP 5.6 ;) related: http://stackoverflow.com/questions/26835450/how-to-get-debuginfo-to-work-with-xdebug – Flion Feb 27 '15 at 11:12

2 Answers2

2

There are tools that provide an intuitive and interactive way to display exceptions and stack traces. Thus you can have all the necessary details and still have an uncluttered UI. Consider the following:

When debugging, you will usually want as much (useful) information as possible, so instead of removing the (at the moment) unnecessary information, try using a library that hides the information by default, but ensures it is there when you need it.

* The Symfony exception handler seems to be able to work standalone (no other dependencies on Symfony judging from composer.json, though I haven't tried it yet). The documentation says:

The ExceptionHandler class catches uncaught PHP exceptions and converts them to a nice PHP response. It is useful in debug mode to replace the default PHP/XDebug output with something prettier and more useful.

Fabian Kleiser
  • 2,988
  • 3
  • 27
  • 44
  • this looks really nice, though my IDE relies on Xdebug for it's debugging work. Not sure if it would be wise to use them together? – Flion Feb 26 '15 at 11:41
  • oh and in the demo I don't see any information on the value of the parameters that were used? – Flion Feb 26 '15 at 11:46
  • Admittedly, I haven't used Whoops before and it does not seem to be able to track the passed parameters. However, I have been using both NetteDebug and Symfony\Debug in projects and both support showing the passed arguments. I have updated the post with new links. – Fabian Kleiser Feb 27 '15 at 07:19
  • thanks, it's a good list. It might come in handy some day, but for now I'm really looking for a solution using xdebug. and it seems __debugInfo is the answer – Flion Feb 27 '15 at 11:10
  • By coincidence I came across the [League](http://thephpleague.com) project which has a nice set of packages, including an error handler called [BooBoo](http://booboo.thephpleague.com/). It is a fairly young project and does not contain a [pretty error page formatter](https://github.com/thephpleague/booboo/issues/5) yet, however the project provides a solid OOP foundation for customizing the error output. I did not add it to the list as it does not yet provide an "intuitive and interactive way to display exceptions". – Fabian Kleiser Mar 03 '15 at 20:25
1

As pointed out in the comment above:

PHP 5.6 supports __debugInfo(). A patch for this method has been submitted to the xdebug repo in dec 2014 and should be released soon.

See also: How to get __debugInfo to work with XDebug?

Community
  • 1
  • 1
Flion
  • 10,468
  • 13
  • 48
  • 68