Webframeworkk/ASP.NET Core/Fehlerbehandlung: Unterschied zwischen den Versionen

Aus Dokument
Zur Navigation springen Zur Suche springen
imported>Import
Version 204
 
Die Seite wurde neu angelegt: „Eine robuste Fehlerbehandlung ist entscheidend für die Erstellung benutzerfreundlicher und stabiler Webanwendungen. In ASP.NET Core MVC geht es darum, Ausnahmen elegant abzufangen, informatives Feedback zu geben und den reibungslosen Betrieb der Anwendung sicherzustellen. ---- == 1. Exception Handling Middleware == Die Middleware zur Ausnahmebehandlung ist eine zentrale Komponente in der ASP.NET Core Request-Pipeline. Sie ermöglicht es, Fehler an eine…“
 
Zeile 4: Zeile 4:
Eine robuste Fehlerbehandlung ist entscheidend für die Erstellung benutzerfreundlicher und stabiler Webanwendungen. In ASP.NET Core MVC geht es darum, Ausnahmen elegant abzufangen, informatives Feedback zu geben und den reibungslosen Betrieb der Anwendung sicherzustellen.
Eine robuste Fehlerbehandlung ist entscheidend für die Erstellung benutzerfreundlicher und stabiler Webanwendungen. In ASP.NET Core MVC geht es darum, Ausnahmen elegant abzufangen, informatives Feedback zu geben und den reibungslosen Betrieb der Anwendung sicherzustellen.


 
----
-----


== 1. Exception Handling Middleware ==
== 1. Exception Handling Middleware ==
Die Middleware zur Ausnahmebehandlung ist eine zentrale Komponente in der ASP.NET Core Request-Pipeline. Sie ermöglicht es, Fehler an einer einzigen Stelle zu verarbeiten.
Die Middleware zur Ausnahmebehandlung ist eine zentrale Komponente in der ASP.NET Core Request-Pipeline. Sie ermöglicht es, Fehler an einer einzigen Stelle zu verarbeiten.


=== Vorteile der Middleware ===
=== Vorteile der Middleware ===
* '''Zentralisierung''': Alle Fehler laufen an einem Punkt zusammen.
* '''Zentralisierung''': Alle Fehler laufen an einem Punkt zusammen.
* '''Eigene Antworten''': Generierung von HTML-Seiten oder JSON-Antworten je nach Fehlertyp.
* '''Eigene Antworten''': Generierung von HTML-Seiten oder JSON-Antworten je nach Fehlertyp.
Zeile 18: Zeile 15:


=== Beispiel: Eigene Middleware (Custom Middleware) ===
=== Beispiel: Eigene Middleware (Custom Middleware) ===
Hier ist ein Beispiel für eine Middleware, die Fehler abfängt und mit einem Logger (z. B. Serilog) protokolliert:
Hier ist ein Beispiel für eine Middleware, die Fehler abfängt und mit einem Logger (z. B. Serilog) protokolliert:


<syntaxhighlight lang="csharp">public class ExceptionHandlingMiddleware
<syntaxhighlight lang="csharp">
public class ExceptionHandlingMiddleware
{
{
     private readonly RequestDelegate _next;
     private readonly RequestDelegate _next;
Zeile 46: Zeile 43:
         }
         }
     }
     }
}</syntaxhighlight>
}
</syntaxhighlight>


-----
----


== 2. Integrierte Middleware-Komponenten ==
== 2. Integrierte Middleware-Komponenten ==
Zeile 55: Zeile 53:


=== Entwicklung: <code>UseDeveloperExceptionPage()</code> ===
=== Entwicklung: <code>UseDeveloperExceptionPage()</code> ===
Diese Middleware wird nur in der '''Development'''-Umgebung aktiviert. Sie zeigt detaillierte Informationen wie den Stack-Trace und Debug-Infos an, was die Fehlersuche erheblich erleichtert.
Diese Middleware wird nur in der '''Development'''-Umgebung aktiviert. Sie zeigt detaillierte Informationen wie den Stack-Trace und Debug-Infos an, was die Fehlersuche erheblich erleichtert.


=== Produktion: <code>UseExceptionHandler(&quot;/Error&quot;)</code> ===
=== Produktion: <code>UseExceptionHandler("/Error")</code> ===
 
In der '''Produktion''' sollten niemals technische Details nach außen dringen. <code>UseExceptionHandler</code> leitet den Benutzer bei einem Fehler auf eine benutzerfreundliche Seite (z. B. <code>/Error</code>) um.
In der '''Produktion''' sollten niemals technische Details nach außen dringen. <code>UseExceptionHandler</code> leitet den Benutzer bei einem Fehler auf eine benutzerfreundliche Seite (z. B. <code>/Error</code>) um.


 
----
-----


== 3. Benutzerdefinierte Ausnahmen (Custom Exceptions) ==
== 3. Benutzerdefinierte Ausnahmen (Custom Exceptions) ==
Zeile 69: Zeile 64:
Manchmal ist es sinnvoll, eigene Exception-Klassen zu definieren, um domänenspezifische Fehler abzubilden. Diese erben von der Basisklasse <code>Exception</code>.
Manchmal ist es sinnvoll, eigene Exception-Klassen zu definieren, um domänenspezifische Fehler abzubilden. Diese erben von der Basisklasse <code>Exception</code>.


<syntaxhighlight lang="csharp">public class CustomException : Exception
<syntaxhighlight lang="csharp">
public class CustomException : Exception
{
{
     public CustomException() : base() { }
     public CustomException() : base() { }
Zeile 75: Zeile 71:
     public CustomException(string? message, Exception? innerException)  
     public CustomException(string? message, Exception? innerException)  
         : base(message, innerException) { }
         : base(message, innerException) { }
}</syntaxhighlight>
}
</syntaxhighlight>


-----
----


== 4. Konfiguration in <code>Program.cs</code> ==
== 4. Konfiguration in <code>Program.cs</code> ==
Zeile 83: Zeile 80:
So bindest du die Fehlerbehandlung korrekt in deine Anwendung ein:
So bindest du die Fehlerbehandlung korrekt in deine Anwendung ein:


<syntaxhighlight lang="csharp">var app = builder.Build();
<syntaxhighlight lang="csharp">
var app = builder.Build();


if (app.Environment.IsDevelopment())
if (app.Environment.IsDevelopment())
Zeile 96: Zeile 94:


app.UseRouting();
app.UseRouting();
// ... weitere Middleware</syntaxhighlight>
// ... weitere Middleware
</syntaxhighlight>


-----
----


== 5. Best Practices für die Praxis ==
== 5. Best Practices für die Praxis ==
Zeile 106: Zeile 105:
# '''Sicherheit''': Gib keine sensiblen Informationen (Datenbank-Strings, Pfade) in Fehlermeldungen preis.
# '''Sicherheit''': Gib keine sensiblen Informationen (Datenbank-Strings, Pfade) in Fehlermeldungen preis.
# '''Logging''': Protokolliere immer die vollständige Exception inklusive InnerException für das Debugging.
# '''Logging''': Protokolliere immer die vollständige Exception inklusive InnerException für das Debugging.
# '''Status Codes''': Verwende korrekte HTTP-Status-Codes (z.B. 404 für “Nicht gefunden”, 500 für “Serverfehler”).
# '''Status Codes''': Verwende korrekte HTTP-Status-Codes (z.B. 404 für "Nicht gefunden", 500 für "Serverfehler").
 


-----
----


== 6. Tipps für das Vorstellungsgespräch ==
== 6. Tipps für das Vorstellungsgespräch ==


* '''Flow erklären''': Beschreibe, wie Ausnahmen durch die Middleware-Pipeline fließen.
* '''Flow erklären''': Beschreibe, wie Ausnahmen durch die Middleware-Pipeline fließen.
* '''Custom vs. Built-in''': Wisse, wann eine eigene Middleware nötig ist (z.B. für spezielles Logging) und wann <code>UseExceptionHandler</code> ausreicht.
* '''Custom vs. Built-in''': Wisse, wann eine eigene Middleware nötig ist (z.B. für spezielles Logging) und wann <code>UseExceptionHandler</code> ausreicht.
* '''UX &amp; Sicherheit''': Betone die Balance zwischen hilfreichen Informationen für den Nutzer und dem Schutz der SystemInterna.
* '''UX & Sicherheit''': Betone die Balance zwischen hilfreichen Informationen für den Nutzer und dem Schutz der SystemInterna.


----
----
''Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).''
''Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).''

Aktuelle Version vom 27. Februar 2026, 16:37 Uhr

Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).


Eine robuste Fehlerbehandlung ist entscheidend für die Erstellung benutzerfreundlicher und stabiler Webanwendungen. In ASP.NET Core MVC geht es darum, Ausnahmen elegant abzufangen, informatives Feedback zu geben und den reibungslosen Betrieb der Anwendung sicherzustellen.


1. Exception Handling Middleware

Die Middleware zur Ausnahmebehandlung ist eine zentrale Komponente in der ASP.NET Core Request-Pipeline. Sie ermöglicht es, Fehler an einer einzigen Stelle zu verarbeiten.

Vorteile der Middleware

  • Zentralisierung: Alle Fehler laufen an einem Punkt zusammen.
  • Eigene Antworten: Generierung von HTML-Seiten oder JSON-Antworten je nach Fehlertyp.
  • Logging: Protokollierung von Details zur Fehleranalyse.

Beispiel: Eigene Middleware (Custom Middleware)

Hier ist ein Beispiel für eine Middleware, die Fehler abfängt und mit einem Logger (z. B. Serilog) protokolliert:

public class ExceptionHandlingMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<ExceptionHandlingMiddleware> _logger;

    public ExceptionHandlingMiddleware(RequestDelegate next, ILogger<ExceptionHandlingMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }

    public async Task Invoke(HttpContext httpContext)
    {
        try
        {
            await _next(httpContext); // Rufe die nächste Middleware auf
        }
        catch (Exception ex)
        {
            // Fehler protokollieren
            _logger.LogError(ex, "Ein Fehler ist aufgetreten: {Message}", ex.Message);
            // Ausnahme erneut werfen, damit sie weiter oben (z.B. UseExceptionHandler) verarbeitet werden kann
            throw;
        }
    }
}

2. Integrierte Middleware-Komponenten

ASP.NET Core bietet fertige Lösungen für verschiedene Umgebungen:

Entwicklung: UseDeveloperExceptionPage()

Diese Middleware wird nur in der Development-Umgebung aktiviert. Sie zeigt detaillierte Informationen wie den Stack-Trace und Debug-Infos an, was die Fehlersuche erheblich erleichtert.

Produktion: UseExceptionHandler("/Error")

In der Produktion sollten niemals technische Details nach außen dringen. UseExceptionHandler leitet den Benutzer bei einem Fehler auf eine benutzerfreundliche Seite (z. B. /Error) um.


3. Benutzerdefinierte Ausnahmen (Custom Exceptions)

Manchmal ist es sinnvoll, eigene Exception-Klassen zu definieren, um domänenspezifische Fehler abzubilden. Diese erben von der Basisklasse Exception.

public class CustomException : Exception
{
    public CustomException() : base() { }
    public CustomException(string? message) : base(message) { }
    public CustomException(string? message, Exception? innerException) 
        : base(message, innerException) { }
}

4. Konfiguration in Program.cs

So bindest du die Fehlerbehandlung korrekt in deine Anwendung ein:

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.UseDeveloperExceptionPage(); 
}
else
{
    app.UseExceptionHandler("/Error"); 
    app.UseExceptionHandlingMiddleware(); // Eigene Middleware registrieren
}

app.UseRouting();
// ... weitere Middleware

5. Best Practices für die Praxis

  1. Zentrales Management: Nutze Middleware statt try-catch-Blöcke in jedem Controller.
  2. Umgebungsabhängig: Detaillierte Fehler nur lokal, generische Fehlerseiten online.
  3. Sicherheit: Gib keine sensiblen Informationen (Datenbank-Strings, Pfade) in Fehlermeldungen preis.
  4. Logging: Protokolliere immer die vollständige Exception inklusive InnerException für das Debugging.
  5. Status Codes: Verwende korrekte HTTP-Status-Codes (z.B. 404 für "Nicht gefunden", 500 für "Serverfehler").

6. Tipps für das Vorstellungsgespräch

  • Flow erklären: Beschreibe, wie Ausnahmen durch die Middleware-Pipeline fließen.
  • Custom vs. Built-in: Wisse, wann eine eigene Middleware nötig ist (z.B. für spezielles Logging) und wann UseExceptionHandler ausreicht.
  • UX & Sicherheit: Betone die Balance zwischen hilfreichen Informationen für den Nutzer und dem Schutz der SystemInterna.

Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).