Open vsfeedback opened 5 years ago
I think this can be safely attributed to the host of different debugging issues with CE, especially async. But it's good to have it tracked.
Notes
This is related to Just-My-Code being on. If that is off, then the exception is not being reported as uncaught
The call stack is:
at Program.main@8-2.Invoke(Unit _arg1)
at Microsoft.FSharp.Control.AsyncPrimitives.CallThenInvokeNoHijackCheck[a,b](AsyncActivation`1 ctxt, FSharpFunc`2 userCode, b result1)
at Microsoft.FSharp.Control.Trampoline.Execute(FSharpFunc`2 firstAction)
at Microsoft.FSharp.Control.TrampolineHolder.ExecuteWithTrampoline(FSharpFunc`2 firstAction)
at <StartupCode$FSharp-Core>.$Async.Sleep@1355-1.Invoke(Object _arg3)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.TimerQueueTimer.CallCallback()
at System.Threading.TimerQueueTimer.Fire()
at System.Threading.TimerQueue.FireNextTimers()
The Just My Code mechanism thinks the exception is escaping user code because it is not caught by any user code on the callstack before library code occurs
It is possible that annotating either user code or library code with other attributes will improve this. There is some information on Mike Stall's old blog and there is sure to be more information around too https://blogs.msdn.microsoft.com/jmstall/2004/12/31/how-can-i-debug-just-my-code/
It's possible inlining more async implementation into user code would help, though all control constructs would need to be inlined to ensure no library code remains on the stack
The other option is to inline move async/control code to become user code, specifically inlining
from async.fs. This would need an FSharp.Core update and a new entry point for unprotected, non-hijacked invocation of an async (effectively making the "Invoke" function on an async public via a backdoor). In the big picture that would be ok I think.
The following code causes the debugger to break when the exception is thrown. Clearly the exception is handled and so the debugger should not break.
If I continue execution the program continues to run normally; printing "oops" on the screen as expected.
Compare this with the equivalent C# code. This does not break when the exception is thrown. The F# version should behave the same way and not break!
This issue has been moved from https://developercommunity.visualstudio.com/content/problem/314461/debugger-should-not-break-on-f-f-sharp-exception-i.html VSTS ticketId: 666263 These are the original issue comments: (no comments) These are the original issue solutions: (no solutions)