Going on a bug hunt

Here’s some disturbing output.

“
Exception in thread “Thread-0” java.lang.ArrayIndexOutOfBoundsException: 2147483
646
at Figure.nextTurn(Figure.java:799)
at Realm.cycle(Realm.java:83)
at CyclerThread.run(CyclerThread.java:41)
“

Whatever could be going wrong?

I lucked out in a way. My artificial life system has run for hours upon hours without any runtime errors like the one above. That suggests that what went wrong only goes wrong rather rarely. It can be damn hard to track down an intermittent bug. Fortunately, I happened to be running an experiment that was automatically saving populations to files. When I reload the population and run it, I get the same error. That’s going to make it much easier to find the problem and test the fix.

To start with, the error message tells us what number was causing the error,” 2147483.” Somewhere in the system, one of the digital organisms, I call them “figures,” must call a command and send that number. Let me see if I can catch it in the act.

Doesn’t seem to happen in Figure.set(int, int). Let’s check Figure.get(int).

I’m not going to be able to track this down from the handlers. I wrote them to provide hooks in the code, places where downstream programmers and I can implement ways to observe the figures, figure out what they’re doing, and experiment with changing them about. The handlers are miserable debugging tools.

The trouble is that the thread that throws the ……………. Wait………….. what about just using exceptions… that’s what they’re there fore… isn’t it? … right! Try and catch! Why didn’t I think of that before? I had this complicated approach in my head, with passing information between threads. I’m glad I thought of the easy way before I spent too much time on the hard one.

Let me give this a shot.

Alright, I’ve never actually used exception handlers before, so I had to experiment a bit to make sure I know how to use them. It all makes sense, but I’m hungry.

Time for food.

After eating, I got distracted. After distractions, I went to sleep. This morning, I poked at it again.

It’s funny that I’ve never used the try and catch blocks other than when the system forces me to. I’ve been programming for decades, and just never really needed them to debug. I think the only reason I thought that I needed them this time, was because I wrote a test wrong.

Let me make sure that I’m right about this…

That’s the worst of both worlds. I’m right about using the wrong number, but I’ll still need the try and catch blocks—the handler hooks still aren’t catching it. I’ve got nothing against them. It’s just odd that I’ve never needed them before.
In the nasty output that started all this, the number wrapped around the screen. The number causing the error wasn’t 2147483, it was 2147483646.

I still haven’t found the bug, but now I know what color it’s wings are.