# 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 special cases, such as `null` or 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 and want to re-enter a method where you missed a critical spot.

Procedure:

* In the Threads tab, hover over the frame you want to reset, then click the Reset Frame button that appears.

![Reset frame button in the Threads tab](https://resources.jetbrains.com/help/img/idea/2026.2/reset-frame.png)

> **Note:**
> Reset Frame only resets local variables. It does not revert changes to the application's global state.

## Use breakpoint expressions

In order to change the flow of your program, you can use [non-suspending breakpoints](using-breakpoints.html#suspend_policy) that [evaluate an expression](examining-suspended-program.html) when hit. This is useful, for example, when you want to automatically modify your variables during debugging.

```JAVA
public class Demo {

    private static boolean readyToExit = false;

    private void printHello() {
        System.out.println("Hello");
        readyToExit = true;
    }

    public static void main(String[] args) {
        Demo d = new Demo();
        d.printHello();
        // evaluate 'readyToExit = false' here
        if (!readyToExit) main(null);
    }
}
```

In the example, resetting `readyToExit` to `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.

```JAVA
public class Demo {

    private static boolean addDebugLogic;

    public static void main(String[] args) {
        System.out.println("Hello");
        if (addDebugLogic) new Debug().doSomething();
    }
}

class Debug {
    void doSomething() {
        // code goes here
    }
}
```

In the example above, you can use a breakpoint to change the value of the `addDebugLogic` flag, which would in turn add the required debug-specific behavior.

Procedure: Add a non-suspending breakpoint with an expression

1. [Add a breakpoint](using-breakpoints.html#set-breakpoints) at the line where you want to modify the program state.

2. Go to [breakpoint properties](using-breakpoints.html#breakpoint-properties).

3. In the properties of the new breakpoint, clear the Suspend checkbox and enter the expression that will modify the program state in the Evaluate and log field.

## 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.

Procedure:

1. Make sure the current method is selected on the Frames tab, then right-click anywhere in the tab and select Force Return.

![Force Return menu item](https://resources.jetbrains.com/help/img/idea/2026.2/debug_altering_flow_return.png)

2. If the method returns a value (its return type is not `void`), specify the value or an expression that will calculate it.

![Return Value dialog](https://resources.jetbrains.com/help/img/idea/2026.2/debug_altering_flow_return2.png)

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.

3. If the execution point is currently in a `try`,`catch`, or `finally` block and there are lines of code in `finally` that have not been executed, select whether you want to skip them.

![Dialog asks you whether you want to execute code in finally](https://resources.jetbrains.com/help/img/idea/2026.2/debug_altering_flow_force_return_finally.png)

## 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 without having to reproduce the cause or modify the code.

Procedure:

1. Select the current method on the Frames tab, then right-click anywhere in the tab and select Throw Exception.

![Throw Exception menu item](https://resources.jetbrains.com/help/img/idea/2026.2/debug_altering_flow_throw.png)

2. Create the exception  (this can be any `Throwable` including `Error` and checked exceptions that are not handled by the method). Do not use the `throw` keyword in the expression, for example: `new NullPointerException()`

![Exception To Throw dialog](https://resources.jetbrains.com/help/img/idea/2026.2/debug_altering_flow_throw2.png)

## Reload modified classes

When you're making changes to your code, you might want to immediately see how they will behave at runtime without shutting down the process. The HotSwap mechanism lets you do that by reloading the classes changed during a debugging session.

Procedure: Reload all changed files

* Right-click in the editor and select Compile and Reload Modified Files.

* Click Apply HotSwap in the Code changed popup. It appears after you make changes to the code while debugging.

![Code changed popup in the editor](https://resources.jetbrains.com/help/img/idea/2026.2/hotswap-popup.png)

> **Tip:**
> You can disable the Code changed popup by clearing the Suggest HotSwap in the editor when the code is modified checkbox in `Build, Execution, Deployment | Debugger | HotSwap`.

Recompilation happens automatically if the Build project before reloading classes option is enabled in `Settings | Build, Execution, Deployment | Debugger | HotSwap`. Otherwise, you need to recompile the files before reloading (`Build | Recompile` `Ctrl+Shift+F9` (Windows), `⌘ ⇧ F9` (macOS), `⌘ ⇧ F9` (IntelliJ IDEA Classic (macOS)), `⌘ ⇧ F9` (macOS System Shortcuts), `Ctrl+Shift+F9` (XWin), `Ctrl+Shift+F9` (GNOME), `Ctrl+Shift+F9` (KDE), `Ctrl+Shift+F9` (Emacs), `Ctrl+B` (Sublime Text), `⌘ B` (Sublime Text (macOS)), `F9` (NetBeans), `Ctrl+F7` (Visual Studio), `⌘ F7` (Visual Studio (macOS)), `Ctrl+Shift+F9` (Eclipse), `⌘ ⇧ F9` (Eclipse (macOS))).

The scope of recompilation depends on the build tool. For example, Gradle and Maven recompile the whole module, whereas IntelliJ IDEA's build system only recompiles the changed files.

Procedure: Reload a single changed file

1. Press `Ctrl+Shift+A` (Windows), `⌘ ⇧ A` (macOS), `⌘ ⇧ A` (IntelliJ IDEA Classic (macOS)), `⌘ ⇧ P` (macOS System Shortcuts), `Ctrl+Shift+A` (XWin), `Ctrl+Shift+A` (GNOME), `Ctrl+Shift+A` (KDE), `Escape, X` (Emacs), `Ctrl+Shift+P` (Sublime Text), `⌘ ⇧ P` (Sublime Text (macOS)), `Ctrl+I` (NetBeans), `Ctrl+Shift+A` (Visual Studio), `⌘ ⇧ A` (Visual Studio (macOS)), `Ctrl+Shift+A` (Eclipse), `⌘ 3` (Eclipse (macOS)).

2. In the [Search Everywhere](searching-everywhere.html) dialog that opens, type `Compile And Reload File`, select the corresponding action, then press `Enter` (Windows), `⏎` (macOS), `⏎` (IntelliJ IDEA Classic (macOS)), `⏎` (macOS System Shortcuts), `Enter` (XWin), `Enter` (GNOME), `Enter` (KDE), `Enter` (Emacs), `Enter` (Sublime Text), `⏎` (Sublime Text (macOS)), `Enter` (NetBeans), `Enter` (Visual Studio), `⏎` (Visual Studio (macOS)), `Enter` (Eclipse), `⏎` (Eclipse (macOS)).

You can configure automatic reloading of classes after they have been recompiled using the Reload classes after compilation option in `Settings | Build, Execution, Deployment | Debugger | HotSwap`. You can turn automatic reloading on/off, or configure the debugger to ask you whether to reload the file in each specific case.

### HotSwap limitations

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. In this case, the frame is displayed 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.

## See also

### Reference

[Review compilation and build output](compiling-applications.html#see-results)