Um wirklich 100%ig jede hässliche Original-ASP.NET-Fehlermeldung vor dem Benutzer zu verbergen, was man immer tun sollte, bietet es sich an, die customErrors-Sektion in der web.config zu nutzen:
<customErrors mode="RemoteOnly" defaultRedirect="~/de/error.aspx">
<error statusCode="404" redirect="~/de/error.aspx?Code=404" />
</customErrors>
In diesem Fall leite ich auf eine von mir erstellte error.aspx weiter, in der ich dann je nach übergebenem Code eine differenzierte Fehlermeldung darstelle. Wie man sich gleichzeitig über den Fehler informieren lassen bzw. ihn mitloggen kann, habe ich hier schon einmal geschrieben.
Was aber tun, wenn man einen ganz bestimmten Fehler mit einer eigenen Fehlerseite behandlen möchte, der nicht in der Liste der vorgegebenen Status-Codes zu finden ist?
Dann erledigt man das einfach in Application_Error() - diese Methode wird nämlich bei jeder Exception aufgerufen, und das noch vor der Weiterleitung.
Beispiel: Wenn ValidateRequest aktiviert ist (was es standardmäßig ist), knallt es kräftig, wenn der Benutzer - mit guter oder böser Absicht - gefährlichen Code, z.B. HTML-Tags, eingibt. Als Fehler generiert das einen 500er, einen internen Serverfehler. Möchte man den Nutzer aber nun gezielt Feedback auf den gefährlichen Input geben (500 kann ja auch noch viele andere Ursachen haben), kann man das wie folgt machen:
void Application_Error(object sender, EventArgs e)
{
if (Server.GetLastError().GetType() == typeof(HttpRequestValidationException))
{
Response.Redirect("~/de/error.aspx?Code=1000");
}
}
Man prüft einfach auf den Typ der Exception und leitet dann auf die Fehlerseite weiter. Da dies noch vor der automatischen Weiterleitung auf die definierte Custom-Errors-Fehlerseite passiert, umgeht man dies damit.
Auf der error.aspx kann man nun entsprechend des Codes (es empfiehlt sich ein 4-stelliger, die gibt es nämlich nicht offiziell) eine passende Fehlermeldung ausgeben.
