Sharp

Debugger anfordern

Hin und wieder gibt es den Bedarf den Ablauf eines Programmes zu stoppen und in den Debugger zu springen. Visual Studio bietet hier die komfortable Möglichkeit der Haltepunkte (neudeutsch Breakpoints). Leider gibt es öfter Situationen, an denen ein einfacher Breakpoint nicht ausreicht. Dies ist insbesondere der Fall wenn die jeweilige Zeile 100fach ausgeführt wird, aber man nur bei einer bestimmten Nebenbedingung den Debugger auslösen möchte.

System.Diagnostics.Debugger.Break()

Diese Funktionalität nutze ich beim FBK. Wenn ich die Ausführung einer bestimmten Rolle testen möchte, trage ich in der Xml-Konfigurationsdatei das Attribut ‘debug’ ein.

        <role type="mutateresources" id="BeerMutating" debug="True">
          <input>
            <resource type="Hop" amount="8" />
            <resource type="Brewer" amount="8" />
          </input>
          <output>
            <resource type="Beer" amount="8" />
          </output>
          <outputresearcheffects>
            <researcheffect research="Brewery">
              <multiplicator type="exponential"
                             factor="1"
                             base="1.1"
                             exponentoffset="0"
                             offset="0" />
            </researcheffect>
          </outputresearcheffects>
        </role>

Wird diese Rolle nun ausgeführt, so hält Visual Studio die Ausführung an und ermöglicht ein einfaches Debuggen.

/// <summary>
/// Executes the role
/// </summary>
/// <param name="worldState">Current worldstate</param>
public void Execute(IWorldState worldState)
{
    if (this.Role.IsDebug)
    {
        Debugger.Break();
    }

    this.Role.ExecuteRole(this.RoleStatus, worldState);
}

Nettes Feature…

Tags: , , ,

4 Antworten zu “Debugger anfordern”

  1. MrMarco sagt:

    Was ist mit den conditional breaks, welche man afaik direkt im VS setzen kann?

  2. TheUndeadable sagt:

    Diese sind manchmal einfach nicht ausreichend.
    Ich habe teilweise keine Lust mir die aufrufende Funktion zu suchen, dort nen Haltepunkt mit Nebenbedingung setzen, wenn ich es einfach in der Konfiguration machen kann, die ich sowieso gerade offen habe.

    Gerade bei stabilen Komponenten, die man länger nicht mehr angerührt hat, findet man nicht immer sofort die passende Zeile ;-)

  3. MrMarco sagt:

    Was mir noch auffällt… du hast ja dann Unmengen an Müllcode im Release Candidat.

    Fummelst du das vor dem Erstellen eines Release Candidates jedesmal raus?

  4. Tobias sagt:

    Wenn nutze ich auch eher conditional breakpoints um den “Müllcode” zu vermeiden.
    Debugger.Break() lohnt sich eigentlich nur bei sehr komplizierten Conditions (oder wenn man nur ne Express Edition hat da gibts afaik keine conditional breakpoints)…

Hinterlasse eine Antwort