Der verschluckte Fehler

Es gibt eine Zeile, die in fast jedem gewachsenen Projekt steht und die mehr Zeit gekostet hat als jede andere:

try
{
    VerarbeiteAuftrag(auftrag);
}
catch (Exception)
{
    // ignorieren
}

Was hier passiert: Das Programm läuft weiter, als wäre alles gut gegangen. Der Auftrag wurde nicht verarbeitet, aber niemand erfährt es — kein Log, kein Alarm, kein Rückgabewert. Der Fehler taucht Wochen später als «die Zahlen stimmen nicht» wieder auf, und dann sucht ihn jemand an der Stelle, wo die Zahlen falsch sind. Nicht hier.

Der eigentliche Schaden ist nicht der verlorene Auftrag. Es ist die verlorene Information: Der Zeitpunkt, an dem das Problem noch bekannt war, ist vorbei.

catch (Exception) ist fast immer zu breit

Auch ein catch, das protokolliert, fängt zu viel, wenn es Exception fängt:

try
{
    var kurs = await _api.HoleWechselkursAsync("CHF", "EUR");
    return betrag * kurs;
}
catch (Exception ex)
{
    _logger.LogWarning(ex, "Kurs nicht verfügbar, nehme letzten bekannten");
    return betrag * _letzterKurs;
}

Gedacht war: Wenn der Kursdienst nicht erreichbar ist, nimm den letzten Wert. Tatsächlich gefangen wird auch:

• eine NullReferenceException aus einem Programmierfehler in HoleWechselkursAsync,
• eine OutOfMemoryException,
• eine TaskCanceledException, weil der Benutzer abgebrochen hat.

In allen drei Fällen rechnet die Anwendung fröhlich mit einem veralteten Kurs weiter — und ein echter Bug ist zu einer Warnung im Log geworden, die niemand liest.

Fang, was du erwartest:

catch (HttpRequestException ex)
{
    _logger.LogWarning(ex, "Kursdienst nicht erreichbar, nehme letzten bekannten");
    return betrag * _letzterKurs;
}
catch (TaskCanceledException)
{
    throw;                       // Abbruch ist kein Fehler des Kursdienstes
}

throw; und throw ex; sind nicht dasselbe

Das ist der subtilste Fehler in diesem Modul, und er kostet regelmässig eine Debugging-Sitzung:

catch (SqlException ex)
{
    _logger.LogError(ex, "DB-Fehler");
    throw ex;      // ← setzt den
                   //   Stacktrace zurück
}

// Im Log steht als Ursprung
// diese catch-Zeile — nicht die
// Stelle, an der es knallte.

catch (SqlException ex)
{
    _logger.LogError(ex, "DB-Fehler");
    throw;         // ← behält den
                   //   ursprünglichen Trace
}

// Im Log steht die Methode,
// in der der Fehler entstand.

Ausnahmefilter

C# hat für den Fall «fangen, aber nur unter einer Bedingung» eine eigene Syntax — und sie ist besser als ein if im catch-Block:

catch (HttpRequestException ex) when (ex.StatusCode == HttpStatusCode.TooManyRequests)
{
    await WarteUndVersucheErneutAsync();
}