Step over not hitting unwind

[stellarpower]

Hi,

Think this may be a difference between LLDB and GDB, but not 100% sure.

Firstly, since switching on this project, whilst I am getting some weird debugger crashes and missed breakpoints to deal with, the debugger is about five times faster to start, so, grateful for this!

When using gdb, if I step over a call in the current frame, that call throws, and the exception is caught in a higher frame, each time I step, GDB walks me through the stack unwind. This helps me see what is happening and also is critically important for ensuring destructor calls are working as they need to be.

With lldb, it seems that if something throws further down the stack and control never returns normally to the present frame, the application just continues, and I now need to retrigger/restart what caused it.

At least I think this is what is happening, again, the lldb I have on this (very complex) project is being a bit weird and I'm still working out the quirks. Is there a way to change this behaviour? I don't like errors being silently dropped, and also don't want to break on every throw or have to step into everything. I'm used to having gdb walk me through the unwinding and whilst some "current exception" pseudo-object in the locals would be really nice under that, at least when I see the frames going up it's unambiguous what is happening if I'm only paying half attention.

Thanks

[vadimcn]

This is really a LLDB question. CodeLLDB mostly just exposes LLDB features in VSCode UI.

don't want to break on every throw

Maybe callers exclusion would help here?

[stellarpower]

Okay, thanks. I wanted to be sure the extension didn't have any business logic changing things that would mean I'd be sent straight back here if I asked against lldb. I'll see what they say. Might be a configuration option if others find the behaviour counter-intuitive also(?)