2

I have to use my own 'DebugBreak' and 'DebugAssert' methods in order to have a single line properly-working break or assert:

[System.Diagnostics.Conditional("DEBUG")] //only relevant while coding
[System.Diagnostics.DebuggerHidden] //force VS to stop on the call to this method instead of inside this method
public static void DebugBreak()
{
    System.Diagnostics.Debugger.Break();
}

[System.Diagnostics.Conditional("DEBUG")] //only relevant while coding
[System.Diagnostics.DebuggerHidden] //force VS to stop on the call to this method instead of inside this method
public static void DebugAssert(bool conditionExpected)
{
    if (!conditionExpected)
        System.Diagnostics.Debugger.Break();
}

These methods work perfectly fine, but since this is so common there must be methods that do this in .NET? I want the VS UI to stop exactly where a condition is reached (a call stack is useless for this purpose) and I only want this to happen while debugging - I have no interest in showing obscure messages to the user. I also don't want "#if DEBUG" littered all over the place.

Edit: There seems to be massive confusion about what I want - I suggest trying one of my methods in a test project to see the exact behavior I'm talking about.

Edit: Please don't vote to close if you don't understand the question.

Edit: It appears not to be possible - looking at the answer here where the same kludgy use of a wrapper method is required: Can .NET source code hard-code a debugging breakpoint?

Dave Doknjas
  • 6,394
  • 1
  • 15
  • 28
  • 2
    Are you saying that setting a conditional breakpoint doesn't work? – Mark Benningfield Mar 06 '21 at 15:59
  • @MarkBenningfield: No, I'm not talking about setting a breakpoint by clicking the left of a statement in the VS UI. I want the conditions to be set in my codebase. – Dave Doknjas Mar 06 '21 at 16:02
  • 2
    What is it about the `System.Diagnostics.Debug.Assert()` method that doesn't do what you want? – Mark Benningfield Mar 06 '21 at 16:05
  • 1
    Questions seeking 'why was it designed this way' are typically not answerable and become off topic. I suggest you head over to the dotnet/runtime repository and request such a feature – pinkfloydx33 Mar 06 '21 at 16:06
  • That method doesn't bring me immediately to the actual point in code that triggers the problem - I don't need a call stack - I just want to immediately see that line of code (my wrapper methods do this). – Dave Doknjas Mar 06 '21 at 16:07
  • Can you please show an example of code you want to set conditional breakpoint on where regular VS conditional breakpoints don’t work? – Alexei Levenkov Mar 06 '21 at 16:07
  • @AlexeiLevenkov: see my comment above - I don't want a call stack dialog - I don't want any dialog - I want to stop at that line of code in VS. – Dave Doknjas Mar 06 '21 at 16:08
  • @MarkBenningfield: Try my methods above to see the behavior I want (and that I would have expected to be already available). – Dave Doknjas Mar 06 '21 at 16:09
  • @pinkfloydx33: Perhaps it's poor phrasing on my part - I'm asking about a way to directly do what I have to create methods for. – Dave Doknjas Mar 06 '21 at 16:11
  • If I understand you, you want to be able to assert an invariant in code, but not fail an assertion, just fire a breakpoint? I doubt you will be able to get the .NET team to go for that. – Mark Benningfield Mar 06 '21 at 16:12
  • @MarkBenningfield: Really? I'll be there are more than a few developers that write exactly these 2 methods to get this behavior - they want to instantly be taken to the exact place a condition is broken without affect the release build. – Dave Doknjas Mar 06 '21 at 16:15
  • If you launch the program in the Debugger, it will break right on top of the failed `Debug.Assert()` call. So you want this to happen when not running with the Debugger attached? – Mark Benningfield Mar 06 '21 at 16:23
  • @MarkBenningfield: Well, with the current version of VS 2019 it does not do that - it produces a huge call stack dialog (exactly as the documentation suggests). Please try one of my methods to see the behavior I want. – Dave Doknjas Mar 06 '21 at 16:26
  • 1
    The comment thread is getting a bit too long here, but I would suggest looking at your Debugger settings. – Mark Benningfield Mar 06 '21 at 16:29
  • I completely fail to understand what standard breakpoints and conditional breakpoints do not do that this does. If it has to be in the codebase why not use `Debug.Assert` or `Debugger.Break` directly in the code? – Charlieface Mar 06 '21 at 20:46
  • @Charlieface: Debug.Assert issues a call stack - don't want or need this. Debugger.Break may show up in release builds, so need #if DEBUG wrapper. Try one of my methods in the question and see the behavior I want - I want the same thing with a one-line .NET call, not using the preprocessor. – Dave Doknjas Mar 06 '21 at 22:49
  • As you have already concluded, there is no way to do what you want. Your example code is probably your best option. The only thing provided by the framework is the ability to unconditionally break. – Lasse V. Karlsen Mar 06 '21 at 23:03
  • 1
    Additionally, since you say that "this is so common", I would say that this sounds so uncommon that I wonder why you think this should be added to the framework. It's, in my experience, **very** uncommon to require a hard breakpoint at a certain point in the code **at all times**. Yes, I realize you have a condition there, but still, I have never seen the need for this in all my time as a developer, so I would say this is not common at all. Do you have other examples of how common this is? – Lasse V. Karlsen Mar 06 '21 at 23:05
  • @LasseV.Karlsen: Suppose you have a string parameter and want to ensure that the string passed is not empty - Utility.DebugAssert(!string.IsNullOrEmpty(stringParam)) is what I use now - are you saying that this is a strange thing to do? Or do you wrap all such assertions with "#if DEBUG" ? – Dave Doknjas Mar 06 '21 at 23:32
  • I think this whole use case is very uncommon. If you want an assert, just put one in. I'm not sure what the fuss is about re the call stack, if your code works then the assert is never fired. `Debugger.Break` does not fire if there is no debugger, if you have a debugger you can just put a breakpoint anyway. And I think the better way to ensure parameters are not empty is to use [contracts, which can be statically analyzed](https://stackoverflow.com/questions/20603510/debug-assert-vs-code-contract-usage) – Charlieface Mar 07 '21 at 01:07
  • @Charlieface: From the documentation: "If no debugger is attached, users are asked if they want to attach a debugger" - I *never* want the break/assert included in the release compile. It seems you can't do that without "#if DEBUG" or a separate method. – Dave Doknjas Mar 07 '21 at 01:40
  • No, I don't wrap such things in `#if DEBUG`, I use the conditional attribute for that, I just never come across the uncoditional break, that was all I commented. – Lasse V. Karlsen Mar 08 '21 at 09:06

0 Answers0