One of the most common debugging techniques, 'printf' debugging is particularly popular because most people learn it intuitively when writing their first programs.

'printf' debugging is very accessible because you don't need any special tools for it. When you face your first bugs, even before you know what a debugger is, the natural thing to do is to have your program print variables step by step, so you can follow the execution in the console.

Although it is one of the most basic debugging techniques, it is also widely used by experienced developers. It can help you investigate any type of problem, such as suboptimal routines, inconsistent state, multithreading problems, and more.

As I already mentioned, this technique does not require you to use any special tools, such as an IDE. However, if you are using one, it can make you even more efficient at recording program state.

Note: This article shows features of IntelliJ IDEA. Similar features may or may not be available in other IDEs. If you are using a different tool, consider checking its documentation to see if these features are also present.

live templates

IntelliJ IDEA provides live templates for the most common debug logging patterns. To use a live template for debug logging, enter the corresponding abbreviation and press Tab. IntelliJ IDEA will generate the print statement and insert it into the cursor.

Let's look at a couple of examples.

Register method parameters

public static BufferedImage recolor(BufferedImage in, BufferedImage mask, int newColor) {

    // escriba 'soutp' aquí, luego presione Tab

    return null;
}

Generated code:

public static BufferedImage recolor(BufferedImage in, BufferedImage mask, int newColor) {

    System.out.println("in = "   in   ", mask = "   mask   ", newColor = "   newColor);

    return null;
}

Register values

public static double coolMethod(double parameter) {
    double a = Math.random();
    double b = Math.random();

    // escriba 'soutv' aquí, presione Tab y luego seleccione el valor

    return a * b * parameter;
}

Generated code:

public static double coolMethod(double parameter) {
    double a = Math.random();
    double b = Math.random();

    System.out.println("b = "   b);

    return a * b * parameter;
}

Register method entries

public static BufferedImage recolor(BufferedImage in, BufferedImage mask, int newColor) {

    // escriba 'soutm' aquí

    return null;
}

Generated code:

public static BufferedImage recolor(BufferedImage in, BufferedImage mask, int newColor) {

    System.out.println("ImageUtils.recolor");

    return null;
}

Logging breakpoints

One of the disadvantages of debugging with print statements is that they introduce the overhead of manual management. You can't turn them on and off quickly, and you definitely don't want to make the mistake of shipping and running them in production.

For this reason, if you need to log something for debugging purposes, I would recommend using logging breakpoints, as they are much easier to handle.

To set a logging breakpoint, hold Shift, then click in the margin. Unlike a regular breakpoint, it does not suspend program execution, but instead prints to the console.

By default, this is a message indicating that the program has reached this line. You can also use the options near the Evaluate and log checkbox in the breakpoint settings if you prefer to log the current stack trace or the result of a custom expression.

Note: Be careful with logging expressions. Evaluating those that cause side effects can be a source of new bugs or unexpected behavior. Additionally, when used in hot code, they could significantly slow down your program.

When log breakpoints become numerous, you can track and manage them in the Breakpoints dialog box (Run | View Breakpoints ):

You can even create custom groups for them:

This will help you manage your breakpoints centrally. For example, you can create a group related to a particular bug and save it for later. When the problem disappears, you simply turn it off. This way, if the problem appears again, you don't have to recreate everything from scratch. You simply turn the group back on.

Frequent Event Log

For events that occur a lot during program execution, logging each event individually may be superfluous. Not only does this flood the console with messages, but a lot of I/O interaction can significantly slow down the debugging session.

For these events, it may be useful to use the Pass count function. You can access it in the Breakpoints.

After you have set Pass count to a specific value, the corresponding breakpoint will only be triggered each time it is reached n-times, ensuring that logging does not become a nuisance.

Summary

Whether you're inserting print statements or setting logging breakpoints for debugging, modern tools have features to improve your debugging experience. With this post, I wanted to make sure you are aware of these little tricks that make the whole process more enjoyable.

If you are interested in more articles related to debugging and profiling, check out some of my other articles:

• Debugger.godMode() – Hack a JVM Application with the Debugger
• Troubleshoot Slow Debugger
• What's Wrong with createDirectories()? - Guide to CPU Profiling
• Debug without Breakpoints