C# eigene Exception erstellen: Einfach erklärt mit Beispielen

Stell dir vor, du schreibst ein Bestellsystem für deinen Ausbildungsbetrieb. Ein Kunde bestellt 50 T-Shirts, aber im Lager liegen nur 12. Du wirfst einfach eine `Exception("Bestand zu niedrig")` - und drei Monate später steht dein Kollege vor einem Berg unleserlicher Fehler und flucht, weil er nicht unterscheiden kann, ob der Lagerbestand, die Datenbank oder die Kreditkartenprüfung schiefgelaufen ist.

Genau dafür gibt es eigene Exceptions in C#: Du baust dir Fehlertypen, die exakt zu deiner Domäne passen. Wie das geht, zeig ich dir Schritt für Schritt. Falls du bei try-catch selbst noch unsicher bist, lies vorher C# Exception Handling: Exceptions richtig fangen und behandeln.

Was ist eine eigene Exception in C#?

Eine eigene Exception (auch benutzerdefinierte Exception) ist eine Klasse, die du selbst schreibst und die von `System.Exception` oder einer bestehenden Exception-Klasse erbt. Sie steht für einen spezifischen Fehler in deinem Programm - etwa "Lagerbestand reicht nicht aus" - und kann im Catch-Block gezielt behandelt werden.

Der Mechanismus dahinter ist schlicht Vererbung, eines der vier OOP-Prinzipien. Wenn du dabei Nachholbedarf hast, wirf einen Blick in OOP Prinzipien C#: Die 4 Grundlagen einfach erklärt.

Merke: Eine eigene Exception ist nichts Magisches - sie ist eine ganz normale Klasse, die von `Exception` erbt und dadurch automatisch alles kann, was eine Ausnahme in C# können muss: geworfen, gefangen und mit Stacktrace versehen werden.

Wann lohnt sich eine eigene Exception?

Du brauchst eine eigene Exception, wenn die eingebauten .NET-Typen deinen Fehler nicht sauber beschreiben. `ArgumentNullException`, `InvalidOperationException` und Co. sind universell - deine Fachlichkeit sind sie nicht.

Kernregel: Catch-Blöcke reagieren auf Typen, nicht auf Texte. Mit einer eigenen Exception schreibst du `catch (BestandZuNiedrigException e)` - das geht mit einer generischen `Exception` nicht.

Wie erstellst du eine eigene Exception in C#? Schritt für Schritt

Schritt 1: Klasse anlegen und von Exception erben

Unsere Beispielklasse heißt `BestandZuNiedrigException`. Sie erbt von `Exception`:

public class BestandZuNiedrigException : Exception
{
}

Das reicht theoretisch schon - du könntest sie sofort werfen. Aber ohne eigene Konstruktoren musst du beim Werfen immer den Basiskonstruktor aufrufen, und wichtige Infos wie der fehlende Bestand gehen verloren.

Schritt 2: Konstruktoren definieren

Damit sich deine Exception "natürlich" anfühlt wie eine eingebaute, gibst du ihr dieselben Konstruktoren, die auch `Exception` hat - plus welche für deine eigenen Daten:

public class BestandZuNiedrigException : Exception
{
  // Zusatzinfo: Wie viel fehlt denn nun genau?
  public int FehlendeMenge { get; }

  // Standardkonstruktor
  public BestandZuNiedrigException()
    : base("Der Lagerbestand ist zu niedrig.")
  {
  }

  // Konstruktor mit eigener Nachricht
  public BestandZuNiedrigException(string message)
    : base(message)
  {
  }

  // Konstruktor mit Nachricht + innerer Exception
  public BestandZuNiedrigException(string message, Exception innerException)
    : base(message, innerException)
  {
  }

  // Eigener Konstruktor mit Fachdaten
  public BestandZuNiedrigException(string artikel, int verfuegbar, int benoetigt)
    : base($"Artikel '{artikel}': Es sind nur {verfuegbar} Stueck verfuegbar, "
        + $"benoetigt werden {benoetigt}.")
  {
    FehlendeMenge = benoetigt - verfuegbar;
  }
}

Der Aufruf `: base(...)` reicht die Parameter an den Konstruktor der Basisklasse weiter. Der Konstruktor mit der inneren Exception ist wichtig für die Fehlersuche: Tritt tief unten eine Datenbank-Exception auf und du verpackst sie in deine Fach-Exception, bleibt der ursprüngliche Fehler im Stacktrace erhalten.

Merke: Der Dreiklang aus Standard-, Nachrichten- und InnerException-Konstruktor ist die von Microsoft empfohlene Grundausstattung für eigene Exceptions - Details stehen in der offiziellen Doku auf Microsoft Learn.

Wie wirfst und fängst du eine eigene Exception?

Hier das komplette Praxisbeispiel - eine Bestellfunktion, die wirft, und ein Aufrufer, der gezielt abfängt:

using System;

public class BestandZuNiedrigException : Exception
{
  public int FehlendeMenge { get; }

  public BestandZuNiedrigException(string artikel, int verfuegbar, int benoetigt)
    : base($"Artikel '{artikel}': Nur {verfuegbar} verfuegbar, "
        + $"{benoetigt} benoetigt.")
  {
    FehlendeMenge = benoetigt - verfuegbar;
  }
}

public class Lager
{
  public void PruefeBestellmenge(string artikel, int verfuegbar, int bestellmenge)
  {
    if (bestellmenge > verfuegbar)
    {
      // Eigene Exception werfen, sobald der Fehler erkannt wird
      throw new BestandZuNiedrigException(artikel, verfuegbar, bestellmenge);
    }
  }
}

public class Program
{
  public static void Main()
  {
    Lager lager = new Lager();

    try
    {
      lager.PruefeBestellmenge("T-Shirt", 12, 50);
      Console.WriteLine("Bestellung akzeptiert.");
    }
    catch (BestandZuNiedrigException e)
    {
      // Nur dieser konkrete Fehlertyp landet hier
      Console.WriteLine("Fehler: " + e.Message);
      Console.WriteLine("Nachbestellen: " + e.FehlendeMenge + " Stueck");
    }
  }
}

Die Ausgabe:

Fehler: Artikel 'T-Shirt': Nur 12 verfuegbar, 50 benoetigt.
Nachbestellen: 38 Stueck

Das ist der eigentliche Gewinn: Der Catch-Block greift auf die Zusatzproperty `FehlendeMenge` zu und kann darauf reagieren - etwa automatisch nachbestellen. Mit einer generischen `Exception` hättest du nur einen String, den du mühsam parsen müsstest.

Welche Fehler solltest du bei eigenen Exceptions vermeiden?

Fehler 1: Von der falschen Basisklasse erben

Früher war `ApplicationException` der empfohlene Basistyp für eigene Exceptions. Microsoft riet davon ab - laut aktueller Dokumentation erbt man direkt von `Exception` oder einem passenden eingebauten Typ wie `InvalidOperationException`. In alten Klausuren und Lehrmaterialien taucht `ApplicationException` trotzdem noch auf - wissen solltest du es also, nutzen nicht mehr.

Fehler 2: Konstruktoren nicht an die Basisklasse weiterreichen

// Falsch: Nachricht geht verloren, e.Message bleibt leer
public class BestandZuNiedrigException : Exception
{
  public BestandZuNiedrigException(string message)
  {
  }
}

// Richtig: base() reicht die Nachricht nach oben
public class BestandZuNiedrigException : Exception
{
  public BestandZuNiedrigException(string message)
    : base(message)
  {
  }
}

Ohne `: base(message)` landet dein Fehlertext nie in der `Message`-Property - und genau die liest dir jeder Logger und jedes Fehlerfenster aus.

Fehler 3: Eine Exception-Klasse für alles bauen

Wenn `MeineException` für Datenbankfehler, Validierungsfehler und abgebrochene Downloads steht, hast du nichts gewonnen. Pro Fachthema eine Klasse - oder eine gemeinsame Basisklasse mit Ableitungen, wenn du Fehlergruppen zusammen abfangen willst. Das funktioniert wie bei eingebauten Typen: `catch (Exception e)` fängt alles, `catch (LagerException e)` nur deine Lager-Familie.

Übungstipp: Kleine Bibliotheks-Exception bauen

Nimm ein Projekt, das du sowieso schreibst - z. B. eine kleine Bücherverwaltung für die Berufsschule. Baue eine `BuchNichtVerfuegbarException` mit einer Property `VoraussichtlicheRueckgabe` (Typ `DateTime`), wirf sie, wenn ein ausgeliehenes Buch erneut ausgeliehen werden soll, und fange sie im Aufrufer. Das dauert 20 Minuten und wiederholt nebenbei Vererbung, Konstruktoren und Properties - drei Prüfungsklassiker der IHK-Prüfung für Fachinformatiker.

FAQ: Häufige Fragen zu eigenen Exceptions in C#

Muss der Klassenname auf "Exception" enden?

Ja, unbedingt. Das ist eine Konvention in .NET, die jeder Entwickler erwartet. `BestandZuNiedrigException` liest sich sofort als Fehlertyp - `BestandZuNiedrig` wäre verwirrend und würde in Code-Reviews zu Recht bemängelt.

Soll ich von Exception oder von einem eingebauten Typ erben?

Beides ist erlaubt. Direkt von `Exception` erben ist der Standardweg. Erbst du z. B. von `InvalidOperationException`, klinkst du dich in bestehende Catch-Blöcke ein, die diesen Typ abfangen - tu das nur, wenn die Semantik wirklich passt.

Sind eigene Exceptions langsam?

Ja, relativ. Das Werfen einer Exception ist teuer, weil der Stacktrace eingefroren wird. Exceptions sind für Ausnahmen gedacht, nicht für normale Programmabläufe - ein leeres Lager ist je nach Fachlichkeit beides. Tritt ein Fall häufig auf, ist ein Rückgabewert (z. B. ein `bool` oder ein Result-Objekt) oft die bessere Wahl.

Wie serialisiere ich eigene Exceptions?

Früher markierte man eigene Exceptions mit `[Serializable]` und implementierte einen Deserialisierungs-Konstruktor. In modernen .NET-Projekten (z. B. mit JSON) brauchst du das meist nicht mehr. Nur bei alter `BinaryFormatter`-Infrastruktur wird es relevant - als Einsteiger kannst du das Thema getrost überspringen.

Gibt es das auch in anderen Sprachen?

Ja, das Konzept ist universell. In Python leitest du eigene Exceptions ebenfalls von `Exception` ab - der Beitrag Python eigene Exception erstellen: Einfach erklärt mit Beispielen zeigt es, falls du im Studium mit mehreren Sprachen hantierst.

Fazit

Eigene Exceptions in C# sind kleiner Aufwand mit großer Wirkung: Klasse anlegen, von `Exception` erben, die drei Standardkonstruktoren mit `base(...)` weiterreichen, nach Bedarf eigene Properties für Fachdaten ergänzen - fertig. Dein Code wird lesbarer, deine Catch-Blöcke präziser und deine Fehlermeldungen für Kollegen und Logs deutlich aussagekräftiger. Genau dieses Wissen begegnet dir in der Abschlussprüfung, im Studium und im ersten Job überall dort, wo Fachfehler sauber behandelt werden müssen.

Wenn du bei Vererbung, Konstruktoren oder Exception Handling noch Bauchschmerzen hast: Die Nachhilfe-Lehrer von study-it.education erklären dir genau die Themen, die in Klausur und IHK-Prüfung drankommen - individuell und auf deinem Niveau. Schau vorbei und mach aus "irgendwie kaputt" ein "verstanden und anwendbar".