Runtime: [Feature request] Debugger.Break on condition
It would be nice to have an opportunity to break when a condition is true.
Sample use case:
Current look:
```c#
List
After such a feature fot added:
```c#
List<object> cObjects = new List<object> { 1, 2, 3, "Hello World", null };
cObjects.ForEach(x =>
{
Debugger.Break(x is int);
});
It doesnt make the code shorter but i think it looks cleaner after such an addition.
Related: https://github.com/dotnet/coreclr/issues/13889
[EDIT] Added C# syntax hihglight by @karelz
JKamsker
All 14 comments
Are you suggesting to add Break method overload?
c#
namespace System.Diagnostic
{
class Debugger
{
public static void Break(bool condition);
}
}
BTW: API requests should follow the standard template as showed in the example in API review doc.
karelz
on 10 Sep 2017
I always type if (condition) { } and press F9.
(Because debugger breakpoint conditions in the projects I frequent are regularly flaky and make the program run infeasably slowly.)
jnm2
on 10 Sep 2017
@karelz Thank you for the syntax highlighting, i wasnt able to figure out how to do that proberly :o
Urrm and yes that's what would make (atleast mine) life easier. I know i could just set breakpoints in my projects between if's as @jnm2 suggests but i sometimes prefer Debugger.Break (but primarily in lambda expressions tho)
In addition there is Debug.Assert which only displays the message when the condition says true. Wouldn't it be nice to unify those methods?
JKamsker
on 10 Sep 2017
@J-kit the API I suggested above takes just bool, so you won't get Debug.Assert-style display message. If you want that, you should recommend different API.
BTW: Doesn't Debug.Assert also break under debugger? ... Maybe the right thing is to just use that, instead of Debug.Break ...
karelz
on 10 Sep 2017
Personally, I don't feel like I've ever wanted this functionality, and there is a pretty simple alternative. It's probably not general enough to warrant inclusion on Debugger itself. Why not just write a simple utility method that does this for you?
C#
public static class DebuggerEx
{
public static void BreakIf(bool condition) { if (condition) Debugger.Break(); }
}
mellinoe
on 12 Sep 2017
@karelz As i can see from here its not quite a break, it's a new window (ok you can just press the BreakAll button).
@mellinoe Yea .. sure but to bypass the problem of breaking in the DebuggerEx.BreakIf function, I'd need to create another dll just for that and i want to avoid using unnecessary third party assemblies.
(Edit: Just found the DebuggerNonUserCode attribute, but having such a possibility directly in the Debugger class would be more convenient)
As you can see, there still would be use for a overload(or just a condition with default=true) in the Debugger.Break function :)
JKamsker
on 12 Sep 2017
You don't really need another DLL -- you could just include the source code directly if you're worried about that.
Breaking in the wrong function is a fair point, if a little minor. Following the API review process helps us organize these details, which are important to making decisions about whether or not an API is worth adding.
mellinoe
on 12 Sep 2017
Breaking in the wrong function is a fair point, if a little minor.
Easily solved with [DebuggerNonUserCode] on the method. I do this all the time.
jnm2
on 12 Sep 2017
@jnm2 I already stated that in the edit of my previous commend. But still, wouldn't having all functionalities in one class be more convenient?
JKamsker
on 12 Sep 2017
@jnm2 Thanks for pointing that attribute out. I had no idea it existed -- I was actually going to say that I wish it did because it could help here 😄.
But still, wouldn't having all functionalities in one class be more convenient?
@J-kit It would be more convenient if you are using this function, but IMO I don't think it will be useful to tons and tons of developers. It seems more like a niche helper than a general, universal function. There's cost (both to us as the maintainers, and to users of our libraries) to every API we add. Another problem is: there's a lot more little helpers you could think of like this. How about a Break function taking a Predicate<T>, or conditional overloads for Debugger.Log as well? Right now, it feels like Debugger actually has a pretty good minimal set of functions that need to be there, with extra stuff able to be built on top.
mellinoe
on 12 Sep 2017
Usually questions of the nature “why don’t we put X in the BCL?” come down to who to prioritize and how big we want the BCL to get, versus how frequently people's needs are served by the API.
jnm2
on 12 Sep 2017
It's also easy enough to create a NuGet package that adds source files to your project. I have a set of core utility/helper/extensions that I use in almost all my personal projects.
I have that code in one repo that just publishes a NuGet package to a MyGet feed.
I then just reference that MyGet package from all my projects and easily have the functions available.
tannergooding
on 12 Sep 2017
The only thing i can say is telling you from my point of view (obviously) which is that i use Debugger.Break quite often and i often came to a point where i would have had a use for such a functionallity, thats why i initially opened this issue.
Of course I can understand your situation of not being able to maintain a massive project which this one would result in when you'd accept all requests. My intention was anyways just telling you guys how this api could be improved in a way that (atleast some) developers could make a use of.
At that point i'd like to tell you that i highly appreciate your work on the .Net Framework
JKamsker
on 12 Sep 2017
Closing as resolved per above discussion. Thank you for your feedback @ suggestion @J-kit !
wtgodbe
on 15 Sep 2017
Related issues
nalywa
·
3Comments
matty-hall
·
3Comments
sahithreddyk
·
3Comments
iCodeWebApps
·
3Comments
jkotas
·
3Comments
Most helpful comment
Easily solved with
[DebuggerNonUserCode]on the method. I do this all the time.