Unterklassifizierung von Ausnahmen

Question

Wir sind uns alle einig, dass die Verwendung unterschiedlicher Ausnahmetypen für unterschiedliche Aufgaben der richtige Weg ist.

Aber dann entstehen Geisterdateien wie diese:

/**
 * Zend Framework
 *
 * LICENSE
 *
 * This source file is subject to the new BSD license that is bundled
 * with this package in the file LICENSE.txt.
 * It is also available through the world-wide-web at this URL:
 * http://framework.zend.com/license/new-bsd
 * If you did not receive a copy of the license and are unable to
 * obtain it through the world-wide-web, please send an email
 * to license@zend.com so we can send you a copy immediately.
 *
 * @category   Zend
 * @package    Zend_Dojo
 * @subpackage View
 * @copyright  Copyright (c) 2005-2010 Zend Technologies USA Inc. (http://www.zend.com)
 * @license    http://framework.zend.com/license/new-bsd     New BSD License
 * @version    $Id: Exception.php 20096 2010-01-06 02:05:09Z bkarwin $
 */

/**
 * @see Zend_Dojo_Exception
 */
require_once 'Zend/Dojo/Exception.php';

/**
 * @category   Zend
 * @package    Zend_Dojo
 * @subpackage View
 * @copyright  Copyright (c) 2005-2010 Zend Technologies USA Inc. (http://www.zend.com)
 * @license    http://framework.zend.com/license/new-bsd     New BSD License
 */
class Zend_Dojo_View_Exception extends Zend_Dojo_Exception
{
}

Dann das Gleiche für Zend_Dojo_Exception und dasselbe für Zend_Exception

Gibt es ein allgemeines Konzept für dieses Problem?

Etwas wie throw new \My\Just\Declared\Exception\ (which extends \My\Just\Exception) damit ich nicht all diese Geisterdateien erstellen und benötigen muss?

Answer 1

Sie scheinen sich auf die Idee zu konzentrieren, dass es sich um "Geisterklassen" handelt - Klassen ohne Implementierung oder Marker-Schnittstellen. Offen gesagt, Sie verstehen nicht, worum es geht.

In ZF1 gibt es die Ausnahmeklassen nur auf Komponentenebene, und alle Ausnahmen auf dieser Ebene erhalten die gleiche Ausnahmeklasse. Damit sind eigentlich nur die folgenden Arten von Catches möglich:

• Globale Ebene (catch "Exception")
• Komponentenebene (Abfangen von Ausnahmen auf Komponentenebene)

Dies ist nur geringfügig besser, als einfach überall "Exception" auszulösen; Sie müssen die Ausnahmemeldungen sorgfältig untersuchen, um eine Vorstellung davon zu bekommen, was schief gelaufen ist.

Lesen Sie den Vorschlag sorgfältig durch.

Der Vorschlag zielt darauf ab, zusätzliche Granularitätsebenen bei der Erfassung von Ausnahmen zu ermöglichen:

• Es ist Ihnen egal, welche Ausnahme es ist? Fangen Sie \Exception.
• Sie sind auf der Suche nach Ausnahmen von einer bestimmten Komponente, interessieren sich aber nicht weiter für die Einzelheiten? Fangen Sie die Exception-Schnittstelle dieser Komponente.
• Möchten Sie nach bestimmten Arten von SPL-Ausnahmen suchen? Fangen Sie diese (in ZF2 implementieren Ausnahmeklassen die Komponentenausnahme-Schnittstelle und erweitern die entsprechenden SPL-Ausnahmen).
• Möchten Sie einen bestimmten Ausnahmetyp innerhalb der Komponente abfangen? Fangen Sie sie einfach ab.

Im Grunde erlauben wir eine größere Granularität nur bei der Ausnahme TYP Sie müssen die Meldung nur dann überprüfen, wenn es mehrere Ausnahmen desselben Typs gibt, die durch die jeweilige Operation ausgelöst werden könnten. Normalerweise sollte dies nicht der Fall sein.

Die SPL-Ausnahmen sind semantisch ziemlich reichhaltig, und viele Ausnahmen innerhalb von ZF würden besser als diese Typen kategorisiert werden (z.B. sollten ungültige Argumente eine InvalidArgumentException auslösen; die Unfähigkeit, ein Plugin aufzulösen, wäre eine gute RuntimeException; usw.). Mit ZF1 ist dies nicht möglich - wir müssen von der Ausnahme auf Komponentenebene erben, Punkt. Durch den Wechsel zu einer Marker-Schnittstelle erhalten wir sowohl die Möglichkeit, Ausnahmen auf Komponentenebene als auch auf SPL-Ebene abzufangen - und auch auf einen spezifischeren Ausnahmetyp.

Answer 2

Einige Leute verwenden die Autoloader um Ausnahmen im laufenden Betrieb zu erstellen.

Answer 3

In der Praxis, nicht wirklich... Es gibt jedoch einige Hacks, die Sie durchführen können, wenn Sie WIRKLICH Ich wollte das tun, aber ich glaube immer noch, dass sie böser sind.

Einer dieser Hacks ist zum Beispiel eval Diese Klassen werden über einen Autoloader ins Leben gerufen. Das ist schlecht, denn wenn jemand jemals grep s für die Definition der Ausnahme oder für die Ausnahmen, die Ihr Paket auslöst, werden sie eine ganze Menge von nada im Gegenzug sein...

public static function load($name) {
    $parts = explode('_', $name);
    if (strtolower(end($parts)) == 'exception') {
        //make it extend the proper exception
        array_pop($parts); //get rid of the last Exception bit
        array_pop($parts);
        $parts[] = 'Exception';
        $parent = implode('_', $parts);
        $code = 'class '.$name.' extends '.$parent . '{}';
        eval($code);
    }
}

Aber ich möchte noch einmal betonen, dass dies in der Regel eine schlechte Idee ist.

Ich persönlich erbe von mehreren "Basisausnahmen" (typischerweise die SPL Ausnahmen ). So kann zum Beispiel ein Database_Connection_Exception könnte erweitern RuntimeException wird beim Versuch, eine nicht offene Transaktion zu übertragen, möglicherweise ein Database_Not_In_Transaction_Exception die sich ausweiten könnten LogicException . Der Punkt ist, dass die Deklaration sie separat können Sie mehr als nur gerade heiarchal Vererbung (nicht zu erwähnen ist besser für die Dokumentation, da die Menschen auf einen Blick auf die definierten Ausnahmen zu sehen, und Sie können tatsächlich Methoden überschreiben, um besser auf Ihre Bedürfnisse, wenn angemessen)...

Bearbeiten: Ausgehend von Ihrer Erwähnung von Zend Die Tendenz, eine Ausnahme pro Unterpaket zu machen, habe ich folgendermaßen umgesetzt...

Grundsätzlich habe ich ein paar "globale" Ausnahmen, die in der gesamten Anwendung verwendet werden. Diese umfassen (sind aber nicht beschränkt auf): ClassNotFoundException , FileNotFoundException , NotCallableException und eine ganze Reihe anderer. Im Grunde nur solche, die nicht paketspezifisch sind, aber mehr Bedeutung vermitteln müssen, als es die PHP-Kernausnahmen können...

Dann deklariere ich Ausnahmen nur auf Paketebene. In diesem Verzeichnis ( package/exceptions ) Ich erkläre jede einzelne Ausnahme als notwendig. So kann ein Unterpaket 5 oder 10 Ausnahmen haben, um verschiedene Bedingungen zu unterscheiden, während ein anderes Unterpaket (innerhalb desselben Pakets) keine haben kann. Ich deklariere sie also nach Bedarf, damit die Ausnahme bedeutet, was passiert ist.

Ich tue dies aus einem einfachen Grund. Ich kümmere mich nicht um where die Ausnahme wurde von ausgelöst (und wenn ich wirklich tat, kann ich die Rückverfolgung, die automatisch innerhalb der Ausnahme generiert wird inspizieren). Ich interessiere mich für why wurde die Ausnahme ausgelöst. Und das lässt mich die Ausnahme richtig behandeln...

Answer 4

Aus meiner Sicht sind oder sollten Ausnahmen nur im Entwicklungsmodus sichtbar sein. Im Produktionsmodus sollten dem Benutzer/Client keine Ausnahmen angezeigt werden, sondern eine einfache Seite mit der Meldung "Ein Problem ist aufgetreten" oder etwas Ähnlichem. Diese Ausnahmen sollten bestenfalls protokolliert werden. Unterm Strich sind sie vor allem für die Fehlersuche nützlich oder wenn sie notwendig sind, um den Ausführungsablauf zu steuern (wenn sie erwartet werden). Sie könnten einfach Folgendes auslösen Zend_Exception aber das würde Ihre Ausnahme nur zu allgemein machen und es wäre schwierig, die Ursache in try..catch zu finden

Ich erstelle normalerweise Ghost-Dateien -- wie Sie sie nennen -- meist auf der "Paket"-Ebene oder wenn von einer Methode erwartet wird, dass sie die eine oder andere Ausnahme auslöst (damit ich genau diese spezielle Ausnahme abfangen und konsequent behandeln kann).

Sie können mit vielen Ghost-Dateien aber es macht Ihr Projekt nur übersichtlicher und einfacher zu debuggen. Und da diese Ausnahmen nur bei Bedarf geladen werden, wirkt sich eine große Anzahl von Ausnahmen nicht auf die Leistung aus.

Answer 5

In der Tat hat PHP bereits Unterklassen für Ausnahmen, siehe aquí für die vollständige Liste. Daher ist die Dokumentation über ihre Verwendung recht begrenzt, Sie können prüfen dieser Beitrag über php-Ausnahmen um die Bedeutung der einzelnen Wörter zu verstehen.