It doesn’t appear that an IF Expression can be stepped through in the debugger. Even if the expression contains a function. Even the function breakpoint isn’t hit.
I might like to see in the debugger what is happening in a case like (simplified):
var x := if y then 'true' else 'false';
It would be nice to see during debugging and stepping if the then is executed or the else. Also, I created a function with a breakpoint for something like this:
function myfunc : string;
begin
result := 'true';
end;
var x := if y then myfunc else 'false';
I set a breakpoint in the myfunc result assignment and the debugger never hit it.
What I expected the debugger to do was step to the code that was going to be executed. So if y is true, I would expect the debugger to stop at the call to myfunc, and then allow me to step into it. And if y is false, I would expect the debugger to stop on the ‘false’ value.
In other words, if there is NO function myfunc, I can’t tell which bit of code in the if expression is being executed.
Obviously here, the if expression just depends on y, but if it were a complicated expression and I just wanted to see what the if expression was returning, I couldn’t even see which branch it was taking. Without introducing functions like myfunc.
Does that make sense?
As for the code, I said it was “something like this”. I’m pretty sure I set the y = true in my actual code, but I was trying keep the example simple. Not sure I have the code anymore to see what I actually did. But I thought I was taking the branch that had a breakpoint in the function and it didn’t stop. Perhaps that works right with the version you are using (which is a GOOD thing )
And the actual thing I said was happening was that it didn’t hit the breakpoint. You are stepping. (which I think didn’t work for me either.) Maybe you can check that it hits your breakpoint?
… time passes …
I made some code again and tested. It DOES stop at the breakpoint in the function now. Maybe I didn’t set the y correctly back then. But again, I only introduced the myfunc so that I could tell which expression result was being returned. Without the function, I wouldn’t be able to tell if the if expression was taking the “then” or the “else” branch.
I see what you mean. The trouble is ofc that in the general case, when stepping you want to step over it, not “into it”. There’s no debugger concept of a step into thats actually inside the function itself. So if i were to introduce sequence points inside this, stepping would become really tediou.
I was trying to recall something that was like that. I think if I have a call, and that call has arguments, and the argument is a function, when you F11 on the original call, it will step into the argument function, and when you step out of it, it stops back at the original call line. And then the next F11 would actually take you into the original routine to be called.
So something like that stop back at the call location was what I was looking for. So treat the if expression sort of like a call with an argument that is a function.
So in the “general case” if I want to step over it, I’d use F10. But if I want to step into it, I’d use F11. So if sequence points were added, I could control whether I wanted “tedious” or not.
Yes. The big problem here is that none of the 3 debuggers we use (java, .net, cocoa) supports this concept without actually moving it out of the method, which has quite a lot of overhead so I don’t want to do that of course.
)