Logging & Debugging

C# in Streamer.bot hat keinen klassischen Debugger. Du kannst nicht mit Breakpoints durch den Code steppen wie in Visual Studio. Stattdessen schreibst du dir Werte ins Log und liest dort nach, was wirklich passiert ist. Das Log ist dein Fenster in den Code, und CPH.LogInfo(...) ist das Werkzeug, mit dem du da reinschaust.

Wenn ein Command sich komisch verhält, der falsche Name in die Message rutscht oder die Action gar nicht reagiert: Log auf, mitlesen, Ursache finden.

Doku: docs.streamer.bot · C# Methods

Die fünf Log-Stufen

Das CPH-Objekt bietet fünf Methoden, abgestuft nach Wichtigkeit. Alle landen in derselben Logdatei, aber mit unterschiedlichem Level davor, damit du beim Lesen filtern kannst.

Stufe	Wofür
`CPH.LogDebug(...)`	Feinste Detailausgaben beim Entwickeln. Erscheint nur, wenn das Log-Level niedrig genug steht.
`CPH.LogVerbose(...)`	Sehr ausführliche Spur, mehr als Debug. Selten nötig.
`CPH.LogInfo(...)`	Der Standard zum Mitschreiben. Normale Statusmeldungen, Zwischenwerte.
`CPH.LogWarn(...)`	Etwas ist auffällig, aber kein Abbruch. Z.B. ein leeres Argument, das du abfängst.
`CPH.LogError(...)`	Echter Fehler. Etwas ist schiefgelaufen, das du sehen musst.

Im Alltag reicht fast immer CPH.LogInfo(...). Nimm es als Default, um zu sehen, was dein Code gerade tut. CPH.LogDebug(...) lohnt sich nur, wenn du sehr viel mitschreibst und das Log später wieder ruhig stellen willst, ohne die Zeilen zu löschen: dann hebst du einfach das Log-Level wieder an.

Wo liegt das Log?

Streamer.bot schreibt in eine Logdatei im Logs-Ordner direkt neben der EXE. Wenn deine Installation also in C:\StreamerBot\ liegt, findest du die Logs unter C:\StreamerBot\Logs\. Die aktuelle Datei trägt das heutige Datum im Namen.

In der App selbst kommst du über das Logs-Verzeichnis an dieselben Dateien. Praktisch ist, die Datei in einem Editor offen zu halten, der bei Änderung neu lädt (z.B. Notepad++ mit aktivem Auto-Reload), dann siehst du neue Zeilen live, während du den Command testest.

Wichtig: Compile-Fehler einer C#-Action erscheinen ebenfalls im Log, und zwar beim Speichern der Action (Compile). Wenn die Action nach dem Speichern nicht funktioniert, ist das Log die erste Anlaufstelle.

Beispiel: Zwischenwerte mitschreiben

Der häufigste Debug-Fall: Du liest ein Argument und bekommst ein anderes Ergebnis als erwartet. Statt zu raten, schreibst du den Wert ins Log und siehst schwarz auf weiß, was wirklich ankommt.

public class CPHInline {
  public bool Execute() {
    // rawInput sicher lesen
    if (!CPH.TryGetArg("rawInput", out string rawInput)) {
      CPH.LogWarn("rawInput nicht vorhanden, breche ab");
      return false;
    }

    // Genau mitschreiben, was angekommen ist
    CPH.LogInfo($"rawInput war: {rawInput}");

    string clean = rawInput.Trim().ToLower();
    CPH.LogInfo($"nach Trim/ToLower: {clean}");

    CPH.SendMessage($"Du hast geschrieben: {clean}");
    return true;
  }
}

Im Log liest du danach etwa:

[Info]  rawInput war:  Hallo Welt
[Info]  nach Trim/ToLower: hallo welt

So siehst du sofort, ob ein unerwartetes Leerzeichen, eine Groß- und Kleinschreibung oder ein leerer String die Ursache war. Mit $"..." (String-Interpolation) baust du Variablenwerte direkt in den Text ein, das ist der bequemste Weg.

Compile-Fehler lesen

Wenn der C#-Code beim Speichern nicht kompiliert, läuft die Action nicht und im Log steht eine Fehlermeldung. Typische Fälle:

Fehlendes Semikolon: ; expected
Unbekannter Name: The name 'rawInpt' does not exist in the current context (Tippfehler im Variablennamen)
Falscher Typ: Cannot implicitly convert type 'string' to 'int'

Die Meldung enthält fast immer eine Zeilen- und Spaltenangabe in Klammern, etwa (12,5). Die erste Zahl ist die Zeile, die zweite die Spalte. Damit springst du im Code-Editor genau an die Stelle.

[Error] Compile error: (12,5): error CS1002: ; expected

Hier liegt der Fehler in Zeile 12, Spalte 5: dort fehlt ein Semikolon, meist am Ende der Zeile davor. Lies die Zeile direkt über der gemeldeten, denn ein fehlendes ; wird oft erst in der nächsten Zeile bemerkt.

Häufige Fallen

Log-Level zu hoch eingestellt: Wenn das Level in den Streamer.bot-Einstellungen über Debug liegt, erscheinen deine CPH.LogDebug(...)-Zeilen gar nicht. Nimm im Zweifel CPH.LogInfo(...), das wird fast immer angezeigt.
Zu viel Logging spammt die Datei: Eine CPH.LogInfo(...)-Zeile in einer Schleife, die hundertmal läuft, macht das Log unübersichtlich und groß. Logge gezielt, nicht in jeder Iteration.
Exception geloggt, aber Action bricht trotzdem ab: Ein CPH.LogError(...) schreibt nur die Meldung, es fängt den Fehler nicht ab. Wenn eine unbehandelte Exception fliegt, stoppt die Action danach. Willst du sauber weiterlaufen, brauchst du ein try/catch um den kritischen Teil und loggst im catch.

public class CPHInline {
  public bool Execute() {
    try {
      // riskanter Teil, z.B. Parsen einer Zahl
      int amount = int.Parse("nicht-zahl");
      CPH.SendMessage($"Betrag: {amount}");
      return true;
    } catch (System.Exception ex) {
      CPH.LogError($"Konnte Betrag nicht lesen: {ex.Message}");
      return false;
    }
  }
}

So landet die Ursache im Log und du entscheidest selbst, ob die Action mit return false sauber aussteigt.