Ausnahmen: Ist das eine gute Praxis?

Question

Dies ist in PHP geschrieben, aber es ist wirklich sprachunabhängig.

try
{
    try
    {
        $issue = new DM_Issue($core->db->escape_string($_GET['issue']));
    }
    catch(DM_Exception $e)
    {
        throw new Error_Page($tpl, ERR_NOT_FOUND, $e->getMessage());
    }
}
catch(Error_Page $e)
{
    die($e);
}

Ist verschachtelter try, catch-Blöcke eine gute Praxis zu folgen? Es scheint ein wenig sperrig nur für eine Fehlerseite -. Aber meine Ausgabe Datamanager eine Ausnahme auslöst, wenn ein Fehler auftritt, und ich denke, dass eine gute Möglichkeit der Fehlererfassungs sein

Die Error_Page Ausnahme ist einfach eine Fehlerseite Compiler.

Ich könnte nur pedantisch sein, aber denken Sie, dies ist ein guter Weg, Fehler zu melden und wenn ja, können Sie eine bessere Möglichkeit, dies zu schreiben?

Danke

Answer 1

Sie verwenden Ausnahmen für Seite Logik, und ich persönlich denke, das ist nicht eine gute Sache. Ausnahmen sollten verwendet werden, um zu signalisieren, wenn schlechte oder unerwartete Dinge passieren, nicht die Ausgabe einer Fehlerseite zu steuern. Wenn Sie auf Ausnahmen eine Fehlerseite generieren wollen, sollten Sie mit set_exception_handler . Etwaige nicht abgefangene Ausnahmen durchlaufen werden, was auch immer -Rückrufmethode Sie angeben. Beachten Sie, dass dies nicht die „fatalness“ eine Ausnahme nicht zu stoppen. Nachdem eine Ausnahme durch Ihren Rückruf übergeben wird, wird die Ausführung wie normale nach jeder abgefangene Ausnahme stoppen.

Answer 2

Ich glaube, Sie wäre besser, sie nicht nisten. Wenn Sie mehrere Ausnahmetypen, haben mehrere Fänge erwartet.

try{
  Something();
}
catch( SpecificException se )
{blah();}
catch( AnotherException ae )
{blah();}

Answer 3

Das Ideal ist für Ausnahmen auf der Ebene gefangen werden, die sie verarbeiten können. Nicht vor (Zeitverschwendung) und nicht nach (Sie verlieren Kontext).

Also, wenn $ tpl und ERR_NOT_FOUND sind Informationen, die nur „bekannt“ ist nahe den neuen DM_Issue Anruf, zum Beispiel, weil es andere Orte, wo man eine DM_Issue schaffen und würde ERR_SOMETHING_ELSE wollen, oder weil der Wert von $ tpl Variiert , dann sind Sie die erste Ausnahme an der richtigen Stelle zu kontrollieren.

Wie von diesem Ort zu bekommen, um zu sterben, ist eine andere Frage. Eine Alternative wäre, genau dort zu sterben. Aber wenn Sie das tun, dann gibt es keine Möglichkeit, Code dazwischen, etwas zu tun (wie etwas in irgendeiner Weise Clearing oder die Fehlerseite zu ändern) nach dem Fehler, aber vor Abfahrt. Es ist auch gut expliziten Steuerfluss zu haben. Also ich glaube, du bist gut.

Ich gehe davon aus, dass Ihr Beispiel keine vollständige Anwendung ist - wenn es dann ist es wahrscheinlich unnötig ausführlich, und man konnte nur in der DM_Exception catch-Klausel sterben. Aber für eine echte App genehmige ich den Grundsatz der nicht nur aus dem Nichts in der Mitte zu sterben.

Answer 4

Je nach Bedarf kann dies in Ordnung sein, aber ich bin im Allgemeinen recht zögerlich, eine Ausnahme zu fangen, wickeln Sie die Nachricht in einer neuen Ausnahme, und erneut auslösen, weil Sie den Stack-Trace (und möglicherweise andere) Informationen aus der ursprünglichen Ausnahme verlieren in der Verpackungs Ausnahme. Wenn Sie sind sicher, , dass Sie nicht diese Informationen benötigen, wenn die Verpackung Ausnahme prüft dann ist es wahrscheinlich in Ordnung.

Answer 5

Ich bin nicht sicher über PHP aber in z.B. C # können Sie mehr als eine catch-Block-haben, so gibt es keine Notwendigkeit für verschachtelte try / catch-Kombinationen ist.

Generell glaube ich, dass mit try / catch Fehlerbehandlung / endlich ist immer gesunder Menschenverstand, auch für die Ansicht „nur“ eine Fehler-Seite. Es ist eine saubere Art und Weise Fehler zu behandeln und seltsames Verhalten zu vermeiden, abstürzt.

Answer 6

Ich würde nicht eine Ausnahme für die Ausgabe werfen nicht gefunden - es ist ein gültiger Zustand einer Anwendung ist, und Sie nicht über einen Stack-Trace müssen nur angezeigt werden ein 404.

Was Sie brauchen, zu fangen sind unerwartete Fehler, wie SQL-Fehler - das ist, wenn die Ausnahmebehandlung in praktisch. Ich würde den Code ändern, um mehr wie folgt aussehen:

try {
    $issue = DM_Issue::fetch($core->db->escape_string($_GET['issue']));
}
catch (SQLException $e) {
    log_error('SQL Error: DM_Issue::fetch()', $e->get_message());
}
catch (Exception $e) {
    log_error('Exception: DM_Issue::fetch()', $e->get_message());
}

if(!$issue) {
    display_error_page($tpl, ERR_NOT_FOUND);
}
else
{
    // ... do stuff with $issue object.
}

Answer 7

Ausnahmen sollten nur verwendet werden, wenn es ein potenziell Website-breaking Ereignis ist - wie eine Datenbankabfrage nicht richtig ausgeführt wird oder etwas falsch konfiguriert. Ein gutes Beispiel dafür ist, dass ein Cache oder Log-Verzeichnis nicht beschreibbar durch den Apache-Prozess ist.

Die Idee dabei ist, dass Ausnahmen für Dich sind, der Entwickler, Code zu stoppen, die die gesamte Website brechen, damit Sie sie vor der Bereitstellung beheben. Sie sind auch geistige Gesundheit überprüft, um sicherzustellen, dass, wenn die Umgebung ändert (das heißt jemand die Berechtigungen des Cache-Ordners verändert oder das Datenbankschema ändern) die Site angehalten wird, bevor er irgendetwas beschädigen kann.

Also, nein; verschachtelte catch-Handler sind keine gute Idee. In meinen Seiten, Wraps meine index.php seinen Code in einem try ... Cache-Block - und wenn etwas Schlimmes passiert, prüft sie, ob sein in der Produktion oder nicht zu sehen; und entweder E-Mails mich und zeigt eine generische Fehlerseite, oder zeigt den Fehler direkt auf dem Bildschirm.

Denken Sie daran: PHP ist nicht C #. C # ist (mit Ausnahme (hehe, kein Wortspiel beabsichtigt: p) von ASP.net). Für Anwendungen, den Zustand enthalten - während PHP ist eine zustandslose Skriptsprache