Breakpoints

Breakpoints are a debugger feature that instruct the debugger to automatically pause your application when it reaches a certain code location , so that you can inspect its state.

Breakpoints can be configured based on a file location in your code (file and line number), or, for some debug platforms, based on a symbol, such as the name of a function or method.

Adding Breakpoints

There are a few ways to set a breakpoint:

You can click on the line number of a line in the code editor (or on the very left of the line in the editor, if line numbers are hidden) to add a breakpoint, or to remove an existing breakpoint.
You can also toggle a breakpoint on the current line using the "Debug|Add/Remove/Toggle Breakpoint on Current Line" menu item, or the ⌘\ or F9 keyboard shortcut.
Finally, yu can invoke the "Add Breakpoint sheet via the "Debug" menu and use it to manually specify a filename and line number, or a symbol name.

While the first two options are usually the most convenient, the third option is helpful because it lets you set breakpoints on files that are not part of your project (as long as the libraries that the code comes from were compiled with Debug Symbols.

Location-based breakpoints will show as a blue bubble on the left of the code line.

Managing Breakpoints

You can manage your existing breakpoints in two ways: via the "Manage Breakpoints" Sheet that's available through the "Debug" menu (⇧⌘B or Alt+Shift+B), or in the Jump Bar, where breakpoints get their own section, once one or more breakpoints are defined.

The jump bar is also convenient for locating your breakpoints, as selecting a (location-based) breakpoint there will automatically jump to that breakpoint in the code editor, and you can then use Up/Down Navigation (^⌥Up/Down in Fire, Alt+Up/Down in Water) to move between breakpoints.

Breakpoint Status

As your application runs, the debugger automatically tries to resolve breakpoints to the actual memory locations of the code they represent. This can be successful, or fail (for example if a breakpoint is on a line that no code was generated for, or if there are no Debug Symbols.

The status of each breakpoint is indicated in a number of ways:

The bubble shown in the editor on each line with a breakpoint will change color according to the status. When no debug session is active, breakpoints are shown in a light blue. As a debug session starts, the bubble changes to either a solid blue (if the breakpoint was resolved) or red (if there was a problem resolving the breakpoint).
Both the Jump Bar and the "Manage Breakpoints" Sheet will change the icon for breakpoints as they resolve.

Note that depending on the platform, the code for your breakpoints might load incrementally, so not all breakpoints will show as resolved right away, and some might not resolve until execution nears them and the appropriate class or method is loaded or JIT-compiled.

Nonetheless, the breakpoint status indicator is a good help if you are wondering why a certain breakpoint might not be hitting.

Disabling All Breakpoints

You can temporarily disable breakpoints by toggling the "Stop on Breakpoints" (or "Stop on Breakpoints when Testing") option in the "Debug" menu. When breakpoints are disabled, their bubble will show as light gray, instead of blue or red.

Breakpoints can be disabled separately, for regular debug sessions or for Testing sessions.

Disabling Individual Breakpoints

You can also temporarily disable individual breakpoints, without removing them completely. To do that, you can ⌘-Click (Fire) or Ctrl+Click (Water) the breakpoint in the gutter, or right-click in the editor and choose "Disable Breakpoint" (or "Enable Breakpoint", to re-enable it) from the context menu.

Disabled breakpoints will also show as light gray, instead of blue or red.

Clearing All Breakpoints

Finally, you can remove all breakpoints for your solution, using the "Clear All Breakpoints" option in the "Debug" menu.

Breakpoint Persistence

Breakpoints are stored per solution, and will persist across debug sessions and across restarts of Fire or Water. They are stored in a per-user cache file next to the .sln.