Ist es eine gute Übung, dass der Konstruktor eine Ausnahme auslöst?

Auslösen von Ausnahmen im Konstruktor ist nicht eine schlechte Praxis. In der Tat, es ist die nur angemessenen Weg für einen Konstruktor, um anzuzeigen, dass es ein problem gibt; z.B., dass die Parameter ungültig sind.

Jedoch ausdrücklich erklärt oder werfen java.lang.Exception ist fast immer eine schlechte Praxis.

Sollten Sie wählen Sie eine exception-Klasse, entspricht der außergewöhnlichen Bedingung, dass eingetreten ist. Wenn Sie werfen Exception es ist schwierig, für den Anrufer zu trennen, diese Ausnahme aus einer beliebigen Anzahl von anderen möglichen deklarierten und nicht deklarierten Ausnahmen. Dies macht die Fehlerbehebung schwierig, und wenn der Anrufer wählt, um zu verbreiten, sind die Ausnahme, eben das problem breitet sich aus.

Jemand schlug die Verwendung assert für die überprüfung der Argumente. Das problem dabei ist, dass die überprüfung der assert Behauptungen können ein-und ausgeschaltet werden über einen JVM-Befehlszeile festlegen. Mit Behauptungen zu überprüfen, interne Invarianten ist OK, aber mit Ihnen zu implementieren, die eine überprüfung der Argumente, die in Ihr angegebene javadoc ist keine gute Idee ... weil es bedeutet, dass Ihre Methode wird nur streng Umsetzung der Spezifikation bei der assertion-Prüfung ist aktiviert.

Das zweite problem mit assert ist, dass, wenn eine assertion fehlschlägt, dann AssertionError geworfen wird, und die empfangene Weisheit ist, dass es ein schlechte Ideeum zu versuchen zu fangen Error - und Untertyps.

InformationsquelleAutor der Antwort Stephen C

Wie bereits in eine andere Antwort hierdie in Richtlinie 7-3 der Java Secure Coding Richtliniendas werfen einer exception im Konstruktor einer nicht-finalen Klasse öffnet sich ein potenzieller Angriffsvektor:

Leitlinie 7-3 /OBJEKT-3: Verteidigen gegen teilweise initialisiert
Instanzen von non-final Klassen, Wenn ein Konstruktor in einer nicht-finalen Klasse
löst eine Ausnahme aus, können Angreifer versuchen, Zugang zu teilweise
initialisiert Instanzen dieser Klasse. Sicherzustellen, dass eine nicht-Finale Klasse
bleibt völlig unbrauchbar, bis der Konstruktor erfolgreich abgeschlossen wird.

Vom JDK 6 auf, Bau einer subclassable Klasse verhindert werden kann
durch das werfen einer Ausnahme vor dem Objekt-Konstruktor abgeschlossen ist. Zu
dies tun, führen Sie die überprüfungen in einem Ausdruck, der ausgewertet wird
Aufruf von this() oder super().

    //non-final java.lang.ClassLoader
    public abstract class ClassLoader {
        protected ClassLoader() {
            this(securityManagerCheck());
        }
        private ClassLoader(Void ignored) {
            //... continue initialization ...
        }
        private static Void securityManagerCheck() {
            SecurityManager security = System.getSecurityManager();
            if (security != null) {
                security.checkCreateClassLoader();
            }
            return null;
        }
    }

Zur Kompatibilität mit älteren Versionen, eine mögliche Lösung beinhaltet
die Verwendung einer flag initialisiert. Setzen Sie das Kennzeichen, wie die Letzte operation in
einen Konstruktor vor der Rückkehr erfolgreich. Alle Methoden bieten eine
gateway zu kritischen Operationen müssen zuerst konsultieren Sie die Flagge vor
Vorgehensweise:

    public abstract class ClassLoader {

        private volatile boolean initialized;

        protected ClassLoader() {
            //permission needed to create ClassLoader
            securityManagerCheck();
            init();

            //Last action of constructor.
            this.initialized = true;
        }
        protected final Class defineClass(...) {
            checkInitialized();

            //regular logic follows
            ...
        }

        private void checkInitialized() {
            if (!initialized) {
                throw new SecurityException(
                    "NonFinal not initialized"
                );
            }
        }
    }

Außerdem alle Sicherheits-und Kleinschreibung verwendet diese Klassen sollten überprüfen,
der Zustand der Initialisierungs-flag. Im Falle der ClassLoader
Bau, Sie sollten überprüfen, dass Ihre parent-class-loader ist
initialisiert.

Teilweise initialisiert Instanzen einer nicht-finalen Klasse zugegriffen werden kann
über einen finalizer Angriff. Der Angreifer überschreibt die protected abzuschließen
Methode in einer Unterklasse und versucht, zu erstellen eine neue Instanz des
Unterklasse. Dieser Versuch fehlschlägt (im obigen Beispiel der
SecurityManager check-in ClassLoader Konstruktor wirft eine Sicherheit
Ausnahme ist), aber der Angreifer ignoriert einfach jede Ausnahme und wartet
für die virtuelle Maschine zum ausführen der Finalisierung auf die teilweise
initialisierte Objekt. Wenn in diesem Fall die schädliche finalize-Methode
Implementierung aufgerufen wird, was dem Angreifer Zugang zu dieser, eine
Verweis auf das Objekt Finalisiert wurde. Obwohl das Objekt nur
teilweise initialisiert, kann der Angreifer immer noch aufrufen von Methoden für es,
was zur Umgehung der SecurityManager überprüfen. Während die initialisiert
Flagge nicht verhindern, dass der Zugang zu den teilweise initialisiertes Objekt
nicht verhindern, dass Methoden, die auf diesem Objekt zu tun, etwas nützliches für das
Angreifer.

Verwendung einer flag initialisiert, während eine sichere, kann mühsam sein. Einfach
sicherstellen, dass alle Felder in einem öffentlichen non-final Klasse enthalten, die eine sichere
Wert (z.B. null) bis zur Objekt-Initialisierung
erfolgreich darstellen können eine sinnvolle alternative in Klassen, die
nicht security-sensibilisiert.

Mehr als robust, aber auch mehr "verbose", " - Ansatz ist die Verwendung eines "Zeiger auf
Umsetzung" (oder "pimpl"). Der Kern der Klasse ist umgezogen in einen
nicht-öffentliche Klasse mit dem interface-Klasse Weiterleitung von Methodenaufrufen. Jeder
versuche, um die Klasse zu verwenden, bevor er vollständig initialisiert ist, wird Ergebnis
in einer NullPointerException. Dieser Ansatz ist auch gut für den Umgang mit
Klon-und Deserialisierung Angriffe.

    public abstract class ClassLoader {

        private final ClassLoaderImpl impl;

        protected ClassLoader() {
            this.impl = new ClassLoaderImpl();
        }
        protected final Class defineClass(...) {
            return impl.defineClass(...);
        }
    }

    /* pp */ class ClassLoaderImpl {
        /* pp */ ClassLoaderImpl() {
            //permission needed to create ClassLoader
            securityManagerCheck();
            init();
        }

        /* pp */ Class defineClass(...) {
            //regular logic follows
            ...
        }
    }

InformationsquelleAutor der Antwort Hazok

Es ist eine schlechte Praxis zu werfen, Ausnahme, als, das erfordert, dass jemand, der ruft den Konstruktor zu fangen Ausnahme, das ist eine schlechte Praxis.

Ist es eine gute Idee zu haben, einen Konstruktor (oder einer beliebigen Methode) werfen eine Ausnahme, generell IllegalArgumentException, die deaktiviert ist, und damit der compiler nicht zwingen, Sie zu fangen.

Sollten Sie werfen überprüfte Ausnahmen (Dinge, die sich von Exception, aber nicht von RuntimeException), wenn Sie möchten, dass der Anrufer zu fangen.

InformationsquelleAutor der Antwort TofuBeer

Dies ist völlig gültig, ich mache es die ganze Zeit. Normalerweise verwende ich IllegalArguemntException wenn es ein Ergebnis der parameter überprüfen.

In diesem Fall würde ich nicht vorschlagen, behauptet, weil Sie ausgeschaltet sind, in einer Bereitstellung erstellen, und Sie wollen immer, um dies zu verhindern, aber deine sind gültig, wenn Ihre Gruppe hat ALLE Tests mit behauptet eingeschaltet ist, und Sie denken, dass die chance fehlt ein parameter-problem zur Laufzeit, akzeptabler als eine Ausnahme zu werfen, ist vielleicht eher die Ursache für runtime-crash.

Auch ein assert wäre schwieriger für den Aufrufer auffangen, das ist einfach.

Als "Würfe" in Ihrer Methode in javadocs.

InformationsquelleAutor der Antwort Bill K