Open dzzzb opened 2 years ago
There is limited conditional breakpoint support today in the debugger. It has been there added as a slice for a long time, but has not yet been scoped. For now we support max as much as the old C/SIDE debugger has supported. The _ALException is added to the local variables on errors the server sends.
The _ALException is added to the local variables on errors the server sends.
Yes, as I eventually discovered. But this is not at all helpful to users. Until they notice that, they waste hours trying to determine why their expression does not give a visible error but does not work. And why let the debugger continue to run if the language threw an exception? Is it because there's difficulty differentiating AL exceptions from code vs. from the platform?
I will also say that the debugging experience appears to be very poorly documented or at least poorly searchable in this aspect. I found no relevant results for searches like Business Central debugger breakpoint condition OR expression. Something like this should be clearly documented as a gotcha until it's fixed, and be optimised to actually appear in search engines.
Also, am I correct that Hit Count and Log Message type breakpoints are not supported at all by AL? If not, then please can they be disabled in the VSC GUI?
And why let the debugger continue to run if the language threw an exception? Is it because there's difficulty differentiating AL exceptions from code vs. from the platform?
It was not the language throwing an exception. But the debug engine. Not all exceptions stop debugging. On the documentation issue. You have a point that it would be nice that we document something you expect from other debug engines to work and does not work here. Though there is nothing new here. We are compatible with the minimum bar hopefully on conditional breakpoints, the old C/SIDE debugger. This should still be the valid documentation for it. https://docs.microsoft.com/en-us/dynamics-nav/how-to--set-conditional-breakpoints I can see it the other way around had we supported complex expressions in conditional breakpoint evaluation that should have been documented. Else we can just have a huge list. Why don't you also ask why don't we document that we do not support intellisense when adding a watch or using the debug console. Also what about hit counts, log messages. That is also not supported. Why don't we document that we do not support that? The list is big. But hopefully with time all these will be supported.
Spent some time today trying to figure out why "Log Message" didn't appear to produce any output when I saw that the breakpoint's red dot in the editor gutter has a tooltip that tells users that breakpoints of this particular type are not supported.
I feel that "Log Message" would greatly benefit my debugging experience. Thank you in advance for (re)considering adding this to the VS Code extension!
1. Describe the bug I just wasted an hour or two of my life, trying to determine why conditional breakpoints seemingly didn't work, when in fact it appears to be a limitation of the AL extension for VSC - but one that's very quietly reported, nowhere useful, the developer might never see it!!
2. To Reproduce
IsNullGuid(SomeRecord.SomeField)
SomeRecord.SomeField
is clearly not aNullGuid
.3. Expected behavior
4. Actual behavior
_ALException
:_ALException
.5. Versions: