Debug Like a Champion

As Pareto’s Law says: Software development is 20% of the time developing and 80% debugging.

Imagine how powerful you could become if you cut down the debugging time and made the debug process more efficient, finding the root cause of the problem in your code or understanding the workflow of your algorithm.

It would be great to sharpen this critical skill and become an exceptional developer to finding “unexpected features” a.k.a. bugs.

Debugging is more than putting some breakpoints and cross our fingers for the program to hit them.

How the “Java Debug” Works?

When a JVM is running a Java Debug session can be launched and communicate with the JVM through the JDWP protocol.

This JDWP (Java Debug Wire Protocol) describes the format of debugging information and requests between a debuggee and a debugger.

Here “a debugger” can be the most basic one, JDB (Java DeBugger) which is a simple command-line that provides an interface to inspection and debugging of a local or remote JVM.

Also, it can be an IDE debugger, so your IntelliJ | Eclipse | Netbeans debugger is typical of your IDE, it provides a GUI to communicate with the JVM through the JVM TI (JVM Tool Interface), this is why every IDE debugger is quite different from each other, even though they must implement the same interface.

So, the normal flow to debug it may look like this:

• Set the breakpoints before the exception or the wrong workflow occurs.
• Set another Breakpoint after to make sure that everything’s fine.
• Lose your mind with what happens in the middle.

Let’s start with my favorite advanced technique, set your Breakpoint in the exception! Not before, not after.

Exception Breakpoints

If you are getting some unchecked exception or an error in runtime, you should put a Java Exception Breakpoint and take a look into the exception code.

After the exception is launched, you can see inside of the code and the state of the objects before the exception arises. You will reach the exact point where the exception is thrown.

Watchpoints

Instead of doing every execution step and see how variable values change, we can set a Watchpoint on the Class’ members – this debug-point will show us when this member is accessed or modified.

You can set a Watchpoint with a simple click in the left gutter area at a line where the member is declared.

This is very helpful when you know the conditions needed to hit the execution point. You should mark the checkbox for the condition in the Breakpoint properties and write a Boolean expression – when this expression returns true, the Breakpoint will hit.

Method Breakpoints

This is an amazing tool. Instead of putting a Breakpoint in the first line of the method and in the last or return statement, you should set a Method Breakpoint and watch the state of the program when the method enters or exits.

Watch Expressions

You could even want to see a particular value of your program, but this can be either a Boolean expression or a primitive value that one object in your code is holding.

To do this, select the piece of code that you want to watch. In this case, it was resultSet.getString(“name”). This is just because I want to see how the name of the state is changing.

This can help you when you don't have a Class’ member to set a watchpoint, as it can be seen as a temporary local variable watchpoint.

Notes

You can customize your Breakpoint sets to make your debug process faster and efficient. Try to explore your IDE, and you will master it. You can have a full control of the JVM execution even when runtime exceptions have been thrown.

Any other thoughts? Share in the comments!