Exception Breakpoints

I'm really trying to get 'Break on handled exceptions' to work but I just can't seem to get it to break. I've tried many different types but nothing seems to work.

I was hoping just 'Exception' would catch everything anyway as you don't always know what the original exception thrown was, but I have tried others when I know that that exception was thrown but still no break.

Have I just got to accept its another thing we're hoping xdebug is going to get working in the future or am I doing something wrong? 

 

16 comments
Comment actions Permalink

Let's be specific. Please consider this code:

<?php
class TestClass {
    public function testFunction() {
        try {
            throw new Exception();
        } catch (Exception $exception) {
            print "Caught";
        }
    }
}
(new TestClass())->testFunction();

Add an exception breakpoint for the Exception type, and try debugging this code. Would it not stop for you on line 5?

0
Comment actions Permalink

No its not. I've add these breakpoints (desperation!)

0
Comment actions Permalink

I put a breakpoint on the line

(new TestClass())->testFunction();, that stops OK. Then continue and all i see is 'caught' in the console.
0
Comment actions Permalink

Can reproduce that neither in the web mode nor in the CLI one: https://recordit.co/FCzYfrR9Xt
Please enable Xdebug remote log, retry your attempt to debug this code and then upload the log somewhere (like pastebin.com or elsewhere).

0
Comment actions Permalink

Wow, I'd love to be able to do what you showed me there! Here is the paste link https://pastebin.com/5YHyhKPn, the whole log was 78MB but there's a massive bit in the middle with just endless calls like:

[23411] E: E: Not a user defined function ((null))
[23411] E: E: Not a user defined function (getInitializer) etc for 78MB

I cut them out and it's just the top bit and bottom bit pasted - if the bit in the middle can help you let me know. 

To make this log, I just ran your test proc. 

I'm on Debian Buster

0
Comment actions Permalink

The only match for this line on the Internet I was able to find is in the Xdebug 2.9.0 sources:

/* This helper doesn't deal with XDEBUG_BREAKPOINT_TYPE_EXCEPTION, and hence this condition should never match */
    if (brk_info->brk_type == XDEBUG_BREAKPOINT_TYPE_EXCEPTION) {
        ctxt->context->handler->log(XDEBUG_LOG_ERR, "E: Not a user defined function (%s)\n", ctxt->fse->function.function);
    }

...whatever the hell it means.

What I'd do if I was you:

  1. Remove all breakpoints (or at least uncheck them) at Run | View Breakpoints, leaving only the Exception one
  2. Remove all debug watches if any
  3. Update Xdebug to 2.9.4
  4. Try again
0
Comment actions Permalink

Mmmm....unfortunately , I've got the version up to 2.9.4 and disabled all of the breakpoints except the 'Exception' one but nothing still. 

Here's my 20-xdebug.ini, 

I've tried a few other , any suggestions? 

0
Comment actions Permalink

I have also been looking at this: https://www.jetbrains.com/help/phpstorm/debugging-in-the-jit-mode.html,

but unfortunately nothing....

0
Comment actions Permalink

I think that something in your interpreter configuration makes Xdebug fail, but unfortunately, I have no idea what it can be. Are you running the code locally?
If so, can you try some virtual machine (Vagrant, Docker, whatever) instead?

0
Comment actions Permalink

The spooky thing is I had this problem on Windows/Xampp as well as Debian and all the configs are OTB. Bit reluctant to create a VM....

Out of curiosity as I've never seen it working, do you have to know exactly the right exception thrown, the exception base class isn't good enough?

If so, that's often not that helpful anyway as you usually don't know the exact exception thrown in the first instance.

0
Comment actions Permalink

The spooky thing is I had this problem on Windows/Xampp

I am on Windows, here's what I just did:

  1. Downloaded the latest thread-safe PHP binaries, 7.4.4
  2. Unpacked it, copied php.ini-development into php.ini
  3. Downloaded php_xdebug-2.9.4-7.4-vc15-x86_64.dll, copied it to ext, plugged it in in php.ini
  4. Reverted to default config in PhpStorm 2019.3.4 and created a new empty project in it
  5. Copied the snippet to this project, added an Exception breakpoint
  6. Right-clicked the file | Debug | test.php (PHP Script)

Everything worked as expected. I do agree that it would be really spooky if the same doesn't work for you.

do you have to know exactly the right exception thrown, the exception base class isn't good enough?

No, Exception + Error should do the trick in all cases (at least as far as I understand it), all their children should be considered. You can also add Warning and Notice if you want.

0
Comment actions Permalink

Yeah, you can set a breakpoint for a base Exception and it would be still caught on a custom exception:

 

So, you were having this problem on various setups: did you use different PHP interpreters to test this?

 

Am I getting it right that using the code example above breakpoints work correctly on your end? But if you test this on your live code - they don't?

0
Comment actions Permalink

Ah!!! Yes its worked. On Windows, that's something ....but I need to revert to Debian. Every time i say apt-get update php/xdebug it says i've got the latest version though. 

Clearing the config might be a first try...

 

 

 

0
Comment actions Permalink

Oh, just reverted the config to my old config and its broken (luckily!) so its in my config.

Any idea where in my config i might look? 

 

0
Comment actions Permalink

Wow. Good news is I got it working on Debian by clearing config. My only changed setting is adding VS key mapping but I can't remember what else I changed but it seems to be working. Next time I change a setting I'll check its still breaking. 

Thanks for all your help, I'm glad you persisted , its going to save me hours (and hours)

0
Comment actions Permalink

Sorry, it's difficult to tell. You can archive the config folder and share here or send it to us using Help | Contact Support mentioning this forum thread

0

Please sign in to leave a comment.