Alter the program's execution flow
While debugging an application, you typically follow the normal flow of a program. However, there are cases when you need to deviate from it. This can be required in order to reproduce certain conditions or to test how the program deals with issues (for example, processes a
null value or handles an exception).
Also, this is convenient when you need to skip particular parts of the program that aren't related to the problem you are currently examining.
Return to a previous stack frame
IntelliJ IDEA lets you fall back to a previous stack frame in a program's execution flow. This can be useful, for example, if you've mistakenly stepped too far, or want to re-enter a method where you missed a critical spot.
Click the Drop Frame icon on the toolbar of the Debug tool window.
Use breakpoint expressions
In order to change the flow of your program, you can use non-suspending breakpoints that evaluate an expression when hit. This is useful, for example, when you want to automatically modify your variables during debugging.
In the example, resetting
false will make the
printHello method be executed over and over until we disable the breakpoint that resets it.
Also, breakpoint expressions can be utilized to add some logic that you want to be only used during debugging.
Force return from the current method
You can exit a method before it reaches the
return statement and make it return an arbitrary value. This is useful when the problem is related to the return value of the method and not to how it's produced. Force return helps you test how the return values are handled by the program without having to reproduce the conditions that lead to these values.
When you use Force return, the instructions after the current execution point are disregarded.
Make sure the current method is selected on the Frames tab, then right-click anywhere in the tab and select Force Return.
If the method returns a value (its return type is not
void), specify the value or an expression that will calculate it.
Expressions are evaluated in the local context and can use any local variables that have already been declared. The return value must conform to the method's return type.
If the execution point is currently in a
finallyblock and there are lines of code in
finallythat have not been executed, select whether you want to skip them.
Throw an exception
IntelliJ IDEA lets you throw an exception or error from the currently executed method. This is useful when you want to test how a particular type of exception is handled in your program without having to reproduce the cause or modify the code.
Make sure the current method is selected on the Frames tab, then right-click anywhere in the tab and select Throw Exception.
Create the exception (this can be any
Errorand checked exceptions that are not handled by the method). Do not use the
Reload modified classes
Sometimes, when you're making minor changes to your code, you want to immediately see how they will behave in a working application without shutting down the process. The HotSwap mechanism lets you reload classes changed during a debugging session without having to restart the entire application.
Reload single file
Right-click in the editor tab of the modified file and select Compile and Reload File.
You can also configure automatic reloading of classes after they have been recompiled using the Reload classes after compilation option in . Automatic reloading can be enabled/disabled, or you can configure it so that the debugger asks you whether to reload the file in each specific case.
Reload all files
From the main menu, select.
Recompilation happens automatically if the Build project before reloading classes option is enabled in . If this option is disabled, you need to recompile the files before reloading ( Ctrl+Shift+F9).
Due to VM design, HotSwap has the following limitations:
it is only available if a method body is modified. Changing signatures is not supported.
adding and removing class members is not supported
if the modified method is already in the call stack, the changes will take effect only after the program exits the modified method. Until that moment, the method body remains unchanged, and the frame is marked as obsolete.
If you want to remove the limitations imposed by the standard VM, you can use the Dynamic Code Evolution VM with unlimited support for reloading classes at runtime.