Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Debug Like a Champion

DZone's Guide to

Debug Like a Champion

Learn how you can make your debugger work for you rather than be at its mercy. Here are a few stopgaps you can implement to narrow down the entire debugging process.

Free Resource

What every Java engineer should know about microservices: Reactive Microservices Architecture.  Brought to you in partnership with Lightbend.

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.

Image title

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:

  1. Set the breakpoints before the exception or the wrong workflow occurs.
  2. Set another Breakpoint after to make sure that everything’s fine.
  3. 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.

Image title

After the exception is launched, we 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.

Image title

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.

Image title

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.

Image title

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.

Image title

Watch Expressions

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

Image title

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!

Microservices for Java, explained. Revitalize your legacy systems (and your career) with Reactive Microservices Architecture, a free O'Reilly book. Brought to you in partnership with Lightbend.

Topics:
debug ,java ,java ee ,ide

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}