2009-06-10 3 views
16

Ich frage mich, ob es eine schlechte Praxis ist, alle PHP-Fehler global in Ausnahmen zu konvertieren. So etwas wie die folgenden verwendet werden würde:PHP - Konvertieren aller Fehler in Ausnahmen - gut oder schlecht?

function exception_error_handler($errno, $errstr, $errfile, $errline) { 
    throw new ErrorException($errstr, 0, $errno, $errfile, $errline); 
    return false; 
} 

Ich nehme an, die Annahme ist, dass Sie gerade beginnen mit „try/catch“ um bestimmte Teile des Codes, die normalerweise Fehler werfen würde.

Wenn es kein Fall von Gut/Schlecht ist, was könnten dann die "Gotchas" sein, die sich aus dieser Übung ergeben könnten?

Antwort

8

Leider funktioniert dies nicht bei fatal/parse/etc. Fehler ...

Ich erinnere mich nicht genau, aber ich habe es versucht und in einigen Fällen eine Nachricht wie "kann keine Ausnahme ohne Workaround ..." werfen, aber ich kann mich nicht erinnern, die Bedingungen zu erhalten dieses Ergebnis. Aber jetzt benutze ich diesen Weg und völlig zufrieden.

+0

Diese Antwort scheint die Frage zumindest ab dem Zeitpunkt ihrer Annahme am besten zu verstehen. Ich verachte es, meine eigenen Fragen zu beantworten, aber ich bin vielleicht später zurück. –

2

Verwenden Sie Ausnahmen für Dinge, die wirklich außerhalb Ihrer Kontrolle liegen.

Gut:

try { 
    if (fopen('file.txt', 'w') === false) { 
     throw new Exception('File could not be opened for write access.'); 
    } 
} catch (Exception $e) { 
    echo $e->getMessage(); 
} 

Bad:

try { 
    if (strlen($_POST['username']) < 5) { 
     throw new Exception('Username too short'); 
    } 
} catch (Exception $e) { 
    echo $e->getMessage(); 
} 

Der erste Weg ist gut, weil es tritt auf, wenn seine etwas, das der Benutzer oder die Anwendung kann nicht Kontrolle. Es kann die Datei nicht öffnen, weil? könnte viele Gründe haben.

Der zweite Weg ist eine Overkill-Verwendung von try/catch, wenn Sie trigger_error verwenden sollten. Die zweite Möglichkeit besteht darin, dass der Benutzer die Regeln der Benutzernamenvalidierung nicht kennt.

Kurz gesagt Ausnahmen, wenn Sie nicht kontrollieren können, was Sie testen. Denken Sie daran, Ausnahmen haben mehr Overhead als auch trigger_error :)

+1

Normalerweise gibt es Fehler, die wir nur für Benutzer anzeigen möchten, und Fehler, die protokolliert werden sollten und nur dem Benutzer angezeigt werden. so "Interner Fehler # 123. Bitte kontaktieren Sie den Support.". In diesem Modell sind Ausnahmeklassen recht formalisiert, um dieses Ergebnis zu erreichen. Also, das 1. Beispiel sollte protokolliert werden, aber 2. nur für den Benutzer und sie sollten das sein. SystemException und UserException ... Nun, ich bin mir nicht sicher, ob 2nd exapmle "overkill use" ist. – Jet

+0

Es mag zunächst nicht als Overkill erscheinen, aber dann müssen Sie über Leistungsprobleme nachdenken. Ein Objekt wird jedes Mal erstellt, wenn eine Ausnahme auftritt. Während das an sich nicht langsam ist, ist es nicht annähernd so schnell wie etwas wie trigger_error zu nennen. und das zweite Beispiel benötigt keinen try catch. Fügt einfach Overhead hinzu und wenn eine Seite wie diese Tausende von Treffern pro Tag erhält, ist der Leistungsverlust bemerkbar :) Ich persönlich benutze nie versuchen fangen, weil ich nicht die Verwendung dafür sehen. – Ozzy

+6

2013 ist hier. Computerressourcen sind kein Problem mehr.Wenn Ihr ausschließliches Anliegen gegen die Verwendung von Ausnahmen ein neues Objekt ist, verwenden Sie wahrscheinlich eine falsche Programmiersprache. – Gajus

1

viele Jahre in Java/.Net in der Vergangenheit gearbeitet und jetzt php in den letzten Jahren, es ist wirklich nervig, all diese verschiedenen Fehlerkonventionen zu haben, während das Exceptions Pattern wirklich ist Gut für alles - angefangen von Fehlern auf Anwendungsebene, Klassenfehlern bis hin zu Systemfehlern - alles.

Ich habe wirklich viel Arbeit in den Versuch investiert, alle Arten von Fehlertypen zu verwalten, weil jede Bibliothek/Funktion Fehler unterschiedlich behandelt.