Well, after a little digging, you can do this, but it will not work in all cases.
Beware, this uses macros and cannot be guaranteed to work with built-in delegates; or with methods that really need to return something. It automates the process described by @juergen d and @Erno when a breakpoint is hit; using very simple heuristics to find where the end of the current function is located.
First you need to add this macro to the macro environment (open with ALT + F11 in VS). This code is probably not as good as it can be, since I just selected it :)
Sub ExitStack() 'get the last-hit breakpoint Dim breakPoint As EnvDTE.Breakpoint breakPoint = DTE.Debugger.BreakpointLastHit() 'if the currently open file is the same as where the breakpoint is set '(could search and open it, but the debugger *should* already have done that) If (DTE.ActiveDocument.FullName = breakPoint.File) Then Dim selection As EnvDTE.TextSelection = DTE.ActiveDocument.Selection Dim editPoint As EnvDTE.EditPoint 'move the cursor to where the breakpoint is actually defined selection.MoveToLineAndOffset(breakPoint.FileLine, breakPoint.FileColumn) Dim codeElement As EnvDTE.CodeElement codeElement = DTE.ActiveDocument.ProjectItem.FileCodeModel.CodeElementFromPoint(selection.ActivePoint, vsCMElement.vsCMElementFunction) 'if a function is found, move the cursor to the last character of it If Not (codeElement Is Nothing) Then Dim lastLine As EnvDTE.TextPoint lastLine = codeElement.GetEndPoint() selection.MoveToPoint(lastLine) selection.StartOfLine(vsStartOfLineOptions.vsStartOfLineOptionsFirstText) 'execute the SetNextStatement command. 'Has to be done via ExecuteCommand DTE.ExecuteCommand("Debug.SetNextStatement") End If End If End Sub
Now you can set your breakpoint - right-click on it and select the menu item When hit... (this only works in VS2010). ScottGu describes this in this blog post.
In the dialog box, locate the ExitStack macro that you just pasted.
Run the code with the debugger attached, and when the breakpoint is deleted, the rest of the function code should be skipped. This should obey other debugger tricks - for example, conditions, etc.
Note. I used this SO to solve the problem I encountered; I initially called the debugger's SetNextStatement method directly, and it did not work
I have no idea how the methods that should return will behave - in theory they should return that the local value is returning at that time, but in some cases the fact simply will not work!
Similarly, if the breakpoint is in the try / catch block, it will not work, because try / catch must be deleted before you can set the next statement somewhere outside of it.