Eclipse Part 2

This morning at work, I’m forcibly reminded of the other thing I like about Eclipse. Debugging. I had a guy come to me asking why this value wasn’t set at a certain part of the code, and so I put a breakpoint on it, attached to the running process with the Eclipse debugger, forced a schedule change, and when it hit the breakpoint, was able to single step through. I found the problem much quicker than if I’d had to keep adding “System.out.println” statements until I’d narrowed down the problem, like I would have in the past.

For 25+ years I’ve been debugging programs with print statements, core dumps (remember //SYSABEND SYSOUT=A?) and writing out the value of variables on a printout of the source code. Every now and then I’d step through something in dbx or gdb, but that was the exception rather than the rule. Now I can step through the code in the same editor I modify the source in, and actually fix it right then and there. I wonder why it’s taken me so long to discover this?

2 thoughts on “Eclipse Part 2”

  1. Maybe you’d been bitten by a debugger that claimed to be able to watch variables, but doesn’t actually do so? That’s one big feature of not working in a pmachine; debuggers will cheerfully let you set watchpoints on a variable, but will then ignore array overflows, stack crunches, or unexpected aliasing, leaving you muttering curses on the ancestry of the debugger, the compiler, and the hardware it rode in on.

    (On the bright side, having to printf() code into submission and then single-stepping through a network daemon is a /very/ good way to convince oneself to start coding in a far more paranoid manner.)

  2. I haven’t had much luck figuring out how to make Eclipse watch a variable. So far I’ve used it to break at particular places in the code and on exceptions only.

    On the other hand, I’ve been bitten by code where adding print statements caused the problem to go elsewhere.

Comments are closed.