loading...
Cover image for Debug Like a Champion

Debug Like a Champion

pedes profile image Andres Cespedes Morales ・3 min read

debug process

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.
exception breakpoint

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.

inside exception breakpoint

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.

watchpoint

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.

conditional watchpoint

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.

method breakpoint

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.

watch expression

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!

Discussion

pic
Editor guide
Collapse
jonathanhartsf profile image
Jonathan Hart

I think one missing section here is how to best analyze the stack when an eng hits a runtime error. A lot of times the error will be emitted in a different part of the stack where the actual bug exists, and being able to traverse the stacktrace is a valuable skill.

Otherwise a great look into visual debugging!

Collapse
pedes profile image
Andres Cespedes Morales Author

Sure Jonathan, thanks for your advice, I will post the second part of it, on how to read and analyze the stacktrace and dumpstack and also on how to solve issues using a Java profiler.

Thanks.

Collapse
rapidnerd profile image
George Marr

As a Java Developer can certainly agree with everything in this post. Majority of the IDE's have hidden tools for debugging that make it 100% easier to find an issue, especially the break/watch points systems in intelliJ I love them!

Great post :D

Collapse
pedes profile image
Andres Cespedes Morales Author

Thanks for your feedback George.

That's one key to successfully find the root cause and solve the issue, we have to master the tools.

Collapse
mortoray profile image
edA‑qa mort‑ora‑y

I very rarely, if ever, do step debugging or conditional watchpoints anymore. I used to do them, but somehow I've found this process of debugging is actually rather time consuming.

One of my primary methods for debugging is writing more unit tests. Anytime I have an idea, or suspicion, about the error I write a test that tries to emulate it. One great advantage to this approach is that my debugging time isn't lost, it's all encoded in unit tests that will remain with the project.

Of course, that doesn't always work. Catching thrown exceptions in a debugger is something I do often to figure out where an error is happening. I don't step at that point, I just inspect the code. This approach works well if you pepper your code with lots of runtime checks -- anything that even remotely smells funny should raise an alarm of some kind.

Collapse
pedes profile image
Andres Cespedes Morales Author

Thanks for your feedback Eda.

The debugging process is from time to time just a time-consuming activity with no results, but there are some cases as you mentioned that you need to figure out a runtime exception that may occur due to a bad development or a wrong architecture.

This is just an additional tool in the problem-solving process.

Collapse
dwd profile image
Collapse
pedes profile image
Andres Cespedes Morales Author

Thanks for your feedback Dave, looking into it.