Stop statements in Visual Basic

Applies to: Visual Studio Visual Studio for Mac

The Visual Basic Stop statement provides a programmatic alternative to setting a breakpoint. When the debugger encounters a Stop statement, it breaks execution of the program (enters break mode). C# programmers can achieve the same effect using a call to Debugger.Break.

You set or remove a Stop statement by editing your source code. You cannot set or clear Stop statements using debugger commands, as you would a breakpoint.

Unlike an End statement, the Stop statement does not reset variables or return you to design mode. You can choose Continue from the Debug menu to continue running the application.

When you run a Visual Basic application outside of the debugger, a Stop statement launches the debugger if Just-in-Time debugging is enabled. If Just-in-Time debugging is not enabled, the Stop statement behaves as if it were an End statement and terminates execution. No QueryUnload or Unload event occurs, so you must remove all Stop statements from the Release version of your Visual Basic application. For more information, see Just-In-Time Debugging.

To avoid the necessity of removing Stop statements, you can use conditional compilation:

#If DEBUG Then
   Stop
#Else
   ' Don't stop
#End If

Another alternative is to use a Debug.Assert statement instead of the Stop statement. A Debug.Assert statement breaks execution only when a specified condition is not met. Assert statements are automatically removed when you build a Release version. For more information, see Assertions in Managed Code. If you want an Assert statement that always breaks execution in the Debug version, you can do this:

Debug.Assert(false);

Debug.Assert(False)

Yet another alternative is to use the Debug.Fail method:

Debug.Fail("a clever output string goes here");

Debug.Fail("a clever output string goes here")

See also

• Debugger Security
• C#, F#, and Visual Basic Project Types
• Debugging Managed Code