Set Conditional Breakpoints in IDEA

Debugging is Part of the Process

One of the things that I simply cannot stress enough is the fact that all computer programs require at least some debugging for them to function at the highest levels. It is simply the reality of the situation, and there is no getting around this fact. 

If you aren't prepared to spend some time debugging your own creations, then you are probably not in the right business. The fact remains that coders have to do this type of work all the time. 

You could be the best coder in the world and you are still going to discover bugs in your systems, at least some of the time. You might as well accept this as a fact and move on to understanding that you will be spending at least some of your time debugging things that you have just created. You need to do so in order to create a program that people will actually want to use going forward. 

Why You Should Create Breakpoints

When working through your code, you need to set breakpoints at certain junctures in order to make sure you can correct the errors that you may have made at some point before you submitted that code. 

In other words, you need to set breakpoints where you can go back and check on your code and see if there are any flaws that need to be addressed. It is a lot easier to deal with this when you use breakpoints because it means that you can easily go back to a certain point in the code and check on it. 

You can think of breakpoints as somewhat like place keepers. You need them in order to figure out where your code may need some tweaks, and it is critically important that you have those set up exactly where you need to make some corrections.

It is a lot easier to hold your spot when you aren't having to look through the entire code that you have set up. Instead, you are merely going through the parts of your code from the breakpoint that you already set up. That makes a huge difference in how much you can likely get done at any given time. 

Where to Set Your Breakpoints

Setting your breakpoints in just the right spots means looking to get them set up approximately every 1,000 records or so. You don't want to run more records than that before you set your breakpoint or else things could get too unwieldy and complicated to manage. 

People sometimes make the mistake of trying to set up literally millions of records before they insert a conditional breakpoint at any point in their code. That is a huge mistake because it can cause them to end up with significant numbers of records that just aren't easy to navigate through. You do NOT want to try to sift through all of that when you don't need to. 

The 1,000 record mark is considered to be a great place to put some conditional breakpoints in because it is where you will discover that you have seen enough code to know what you are looking for, but not so much code that you can't manage it. 

Going through 1,000 lines of code is something that most people can do fairly quickly when they are looking for a mistake. Looking through a million lines of code is simply impossible. 

Fix Mistakes and Move on

One thing for all coders to keep in mind is the fact that they should correct their mistakes and move on from them as quickly as possible. We are all going to make some mistakes when we code, so it is a good idea to key in on those errors and attempt to get them corrected ASAP. 

There isn't much value in remaining fixated on them when they aren't contributing to your ability to continue to provide amazing work for your clients. Instead, you need to work with the code that you have already put out there and try to fix what you can. 

Don't get too caught up on the fact that you have made an error or two. Just make sure you fix the problems that you made and go from there. If you can fix up the code that needs to be repaired, then you can start to learn from the errors that you previously made. 

Breakpoints are a great way to give yourself a break when working through all of these corrections. You need to ensure that you allow yourself the space you need to get the work done, but you also want to avoid overworking yourself. 

You can accomplish both of these goals by paying attention to how you set up your breakpoints. It is critical that you get this just right, and you can do so by always including breaks. 

The best coders in the world know that they will have to recheck their work multiple times. Try to get it straightened out ahead of time so you can submit code that has been properly checked and reviewed. 

So yesterday I was attempting to debug an issue in a batch processing module within one of our applications. In short, an assertion was failing deep within Hibernate as it attempted to flush the session. 

Using a combination of various log statements, I had isolated the problem down to a particular record that the batch process was attempting to update. (BTW: I know you shouldn't be using Hibernate for batch processing - however, we're talking about batches of at most 1000 records here, not millions!) 

What I really wanted to do was set a breakpoint and examine the state of the objects at runtime; however, I dreaded the thought of clicking through the breakpoint time and time again until I got to the particular record that was causing the problem. "Surely," I thought, "there must be a way to tell the debugger to only break under certain conditions."

So, here's the code I wanted to examine:

public Publication parsePublication(String inputLine) throws ParseException {        Publication publication = new Publication();        String[] fields = inputLine.split("\t");        publication.setPublicationType(fields[0]);        ...        return publication;} 

Essentially, I wanted to break after inputLine.split("\t"); if and only if fields[35] existed and were equal to "PM:16732581." After examining IDEA's Breakpoint dialog, I noticed a section in the bottom right-hand corner that I'd never played with before:

[img_assist|nid=777|title=|desc=|link=none|align=middle|width=634|height=673]

Asit turns out, this is exactly what I needed. If you click on the ellipsis next to the drop menu, you get a context-sensitive editor equipped with code completion:

[img_assist|nid=778|title=|desc=|link=none|align=middle|width=416|height=233]

Enter the desired conditions and voila! A conditional breakpoint. It worked like a charm the very first time, and I only had to inspect the breakpoint when the problematic record came up.

Another nice feature of the conditional breakpoint is that if some sort of exception (such as a NullPointerException) occurs while attempting to evaluate the conditional expression, IDEA pops up a dialog informing you what happened and asking if you want to stop at the breakpoint or continue. Nice.