Fighting bugs

For the last few days I've been fighting bugs. I've started work on a secret Java project (oh boy!), and as with any big project, there are always bugs. I've squashed a few of 'em, yet more seem to keep working their way out of the cracks, those sneaky little punks. Below is one of the nastiest bugs I've encountered so far. It's a null pointer exception seemingly coming from within the Java virtual machine, but I highly doubt that. Usually, these kinds of exception print out exactly which line of code is causing the issue, but this one is a little more difficult. What I have to do is retrace all my steps and work my way through the flow of variables until I find it, because someone somewhere is calling a method on a null object and it's my job to hunt it down and squish it.

So rather than fix it right this minute, I'm going to blog about it. Because why not?

When a critical error occurs within any higher-level programming language, the code does something called "throwing an exception." When the code throws an exception, it immediately stops what it's doing and follows its path all the way up the program stack, recording every step it takes so that it can print out something useful for the debugger. In the picture, all the lines that start with "at" are steps that the exception took before it printed this error message. If the exception works its way all the way up the program stack without being caught, it kills the program and prints its message to the computer's console. If the programmer is expecting an error like this and wants to handle it in a specific way, he can put the problematic code inside a try{} catch{} statement, and any exception that matches the exception specified in the catch's parameters will stop right there and execute the code inside the catch's block.

 Using these techniques it is possible to make a program more "robust" by being very thorough and catching any error that could possibly occur during normal program usage. If your program is designed for security reasons, like a bank account application, it is imperative that it catch any and all exceptions, so that the bank's servers can remain operational. Otherwise, it would be easy for any hacker to input some malformed code and gain access to the bank's private information and money. So yeah, in today's society, programmers can have just as much responsibility as an armed guard in a bank.

Well, thanks for reading, and everyone enjoy your spring break! (I know I will) 

-Jeff