?

Log in

No account? Create an account
color cycle (slow)

Kistaro Windrider, Reptillian Situation Assessor

Unfortunately, I Really Am That Nerdy

Previous Entry Share Next Entry
The Frustrated Programmer
color cycle (slow)
kistaro
...
   //This can't happen
   if(currentTower.getValue() == null){
      System.err.println("FUCK IT");
      System.err.println("We are about to die");
      System.err.println("THIS CAN'T HAPPEN, DAMMIT");
      System.err.println(currentTower.toString());
   }
   currentTower.value.add(value);
...


This is the sort of thing one can find in my Computer Science 241 homework when I'm tracing any mysterious bug that makes no sense. That block of code was executed, and I just figured out what causes the error (even when not part of the assignment, I make toString() useful).

For me, it's sort of catharitic to see the computer apparently as frustrated as I get, hence cursing code.

  • 1
Seeing the computer come out with those kinds of strings makes me think that your computer has a multiple personality disorder based on the fact that it refers to itself in the plural.

It's a multi-object application about to crash in full measure if it's getting a null pointer there (the first command after the if-block would throw a NullPointerException), so the plural seemed appropriate...

Even though my understanding of the code snip extends to "The computer prints curse words on the screen," it made me laugh anyway. And I read it aloud to two of my friends, and they both cracked up too.

Computers that curse... What will they think of next? Vaccuums that cough and choke when they eat too much hair?

Actually, cursing error messages (swearrors?) aren't that new. Sometimes they even slip into production code; a notable one I read on a newsgroup somewhere was "You don't have DirectX installed, dumbass!" in the first release of something or other. Management was not amused the first time tech support recieved a call from a (rather amused) customer about the error.

What the code block does, by the way:

1. See if the error I'd been getting is happening over here- there's a null pointer somewhere (like a "look over here for data" sign that points nowhere at all) that's been causing a NullPointerException to be thrown, but I'm not sure why.
2. if it is, enter the bracketed block.
3. On the standard console output, print a few obcenities, then give a readout of the object with the null pointer to see if we can identify the state of the program when this happens.
4. End the block. At this point, the code rejoins its split state- if the if-statement evaluated to false, it would just jump here. If it's true, it goes into the block and comes out here.
5. Attempt to access the value at the pointer we just tested for nullularity (nullness, nullitude?). If it's null, of course, we are going to crash miserably, but at least we'll know what's wrong.

Incidentally, that block of code was the only thing that let me track down and fix the bug.

Heee. That's nifty. Thanks for the explanation, by the way - I had half a course of C++, so I have some sketchy idea of how computer logic works, but not enough to follow everything. Usually I can get the gist of it, though.

I would laugh so hard if I ran into an error message in a professional proudct that cursed at me. In fact, I'd probably repeat the error for my friends (if I could - if I had no idea what I did, I'd try to take a screenshot).

  • 1