Scala no-op that is guaranteed not to be optimised away?

Question

You can set a breakpoint on the closing } of a Scala method, but it's pointless to do so because it won't be hit, apparently.

I would still like to set it there. So I thought, "how about I put in a no-op before that line, and set a breakpoint on that?"

But since evidently Eclipse is not warning me when I try to set a breakpoint that will never be hit (because there is no code there), I therefore can't rely on Eclipse telling me if a no-op has been optimised out (particularly as I'm not even using the same version of Scala to run the code as the Eclipse Scala plugin is using).

So is there a short no-operation statement or expression that I can use here which is guaranteed not to be optimised away by the Scala compiler, in all circumstances - and guaranteed not to be optimised away by a JIT in a way that prevents a breakpoint on it being hit? I guess it has to be an expression rather than a statement in my case, because this method returns a useful value, not Unit.

Answer 1

It's not exactly a no-op, but a logging statement (or trace expression - i.e. a logging statement which additionally returns the value it has just logged) is guaranteed not to be optimised away!

The only trouble with that is, you have to manually step over the debug statement or trace expression each time you hit the breakpoint, if you want to see what it actually outputs. Unless it's just outputting the value of a variable, in which case you can find that variable in the Variables tab in Eclipse.

And stepping over a trace expression, at least in my code, with the Eclipse Scala plugin 2.1 milestone 2, in "old-style debugging mode", is no small matter - because it's completely broken, due to this issue!

Before I realised what was going on, it took me about 20 tries of pounding the F6 and F7 keys before I finally managed to step over it! And that was just for stepping over it once!

And remember, the next line is the } - so the obvious workaround, setting another breakpoint on the next line - won't work!

Theoretically you should just be able to Inspect the value being traced, rather than trying to step over the trace. Unfortunately, that doesn't work for me either - it says class not found.