Warum ist Throwable.fillInStackTrace () - Methode public? Warum würde jemand verwenden?

Ich bin neugierig, warum ist die Methode fillInStackTrace von java.lang.Throwable öffentlichkeit?

Diese Methode ersetzt original-stack-trace mit, dass von dem Ort, es heißt, das entfernen der benötigten Informationen zu lokalisieren Ausnahme. Es könnte verwendet werden, für die Verschleierung, aber ohne viel Aufwand, da die neuen stack-trace zu lenken, um die Verschleierung von code. Der bessere Weg wäre, einfach ausblenden Ausnahme oder werfen Sie die neue.

Aber ich kann nicht herausfinden, jede angemessenen Fall für den Aufruf dieser Methode auf bestehende Throwable. Die Frage ist also: warum diese Methode ist öffentlich? Ist da irgendein Sinn hinter?

InformationsquelleAutor Danubian Sailor | 2012-03-20
  1. 44

    Ein Grund ist für die Leistung. Werfen und fangen einer Ausnahme ist Billig, das teuerste Teil ist Füllung in der stack-trace. Wenn Sie überschreiben fillInStackTrace() nichts zu tun, erstellen Sie eine Ausnahme wird auch Billig.

    Mit Billig-Ausnahmen können Sie Ausnahmen für flow control, die machen den code besser lesbar in bestimmten Situationen; Sie können Sie verwenden, wenn bei der Implementierung von JVM-Sprachen, wo Sie brauchen,mehr advanced flow control, und Sie sind nützlich, wenn Sie schreiben eine Akteure Bibliothek.

    • Das ist interessant, aber ist es nicht gegen Konzept von Java zu Kontrollfluss über exceptions?
    • Im Allgemeinen ja, aber wie Sie sehen können, wenn Sie den links Folgen, manchmal ist es sehr nützlich.
    • Ich bezweifle, dass diese Anwendung war die Absicht der Designer
    • Sie bekommen meine bounty, für die meisten Quellen und ein use-case-das ist nicht etwa fragwürdig wertvolle Informationen zu verbergen oder Missbrauch der Semantik.
    • Aber protected hätte Arbeit für diesen Anwendungsfall.
    • Dies beantwortet nicht die Frage, die fragt, warum die Methode ist public. Als jtahlborn erklärt in Ihrer Antwort, es ist öffentlich, so dass ein Aufrufer zurückgesetzt werden kann der stack-trace, z.B. vor dem auslösen einer Ausnahme konstruiert anderswo.

    InformationsquelleAutor sbridges
  2. 20

    Einer möglicherweise legitimen Gebrauch ist die Schaffung einer Ausnahme von einem anderen Ort aus, wo Sie tatsächlich werfen. Zum Beispiel, vielleicht haben Sie eine Anwendung, wo Sie eine plugin-Anlage für die Erzeugung von benutzerdefinierten Ausnahmen. Da der stacktrace ist gefüllt auf Bau, die trace der exception enthalten möglicherweise irreführende Informationen (es werden Anrufe in das eigene exception-Fabrik). also, Ihre Anwendung nennen würde fillInStackTrace() auf die Ausnahme nach generation durch den custom factory, um eine genauere stack-trace für den letztendlichen Empfänger der Ausnahme.

    Diese abgelehnt bug zeigt an, dass Sie nicht die einzige, die verwirrt durch die Notwendigkeit für diese Methode.

    InformationsquelleAutor jtahlborn
  3. 5

    Einen legitimen Anwendungsfall für Throwable.fillInStackTrace() ist für nicht-lokale Ablaufsteuerung:

    Zum Beispiel, in meinem TrueZIP Rahmen, ich benutze eine komplexe Kette von decorators für die Datei-system-Controller. Eine der Steuerungen ist in dieser Kette ist eine Instanz der Klasse FsLockController. Dieses Objekt ist verantwortlich für die Verwaltung einer ReentrantReadWriteLock für das Datei-system. Nun wird ein Datei-system-controller irgendwo tiefer in diese Kette könnte erkennen, dass ein write-lock ist erforderlich, aber nur einen lese-lock erworben wurde, durch die FsLockController. Da können Sie kein upgrade für eine read-Sperre auf eine schreib-Sperre ohne dead-locking, eine exception muss geworfen,, die passiert zu sein eine Instanz der Klasse FsNeedsWriteLockException. Die Dekoration FsLockController dann fangen diese Ausnahme, lassen Sie die read-lock und erwerben die write-lock, bevor Sie den Vorgang wiederholen, wieder.

    Diese Art der nicht-lokalen Ablaufsteuerung funktioniert eigentlich sehr gut, aber es ist eine Sache zu Bedenken: das Werfen und fangen einer Ausnahme ist Billig, aber der Befüllung oder Prüfung der stack trace ist teuer. Jetzt, da diese spezielle exception-Typ ist ausschließlich geworfen und gefangen in dieser Datei-system-controller-chain, ich brauche nicht einen stack-trace an alle und so kann ich sicher überschreiben Throwable.fillInStackTrace() mit einem leeren Methodenrumpf, um zu unterdrücken, um diese teure operation.

    Source-code für die Basis-Klasse dieses Ausnahme-Typ gesehen werden kann hier.

    InformationsquelleAutor Christian Schlichtherle
  4. 3

    Hier ist eine vernünftige Fall: zum ausblenden von details der Anwendung von nicht autorisierten Benutzer. Zum Beispiel wollen Sie nicht aussetzen stack-trace der exception geworfen, wenn der Lizenzschlüssel abgelaufen ist, denn es vereinfacht die hacker-Arbeit.

    • Aber warum in diesem Fall zeigen Sie den stack-trace überhaupt?
    • Sie nicht müssen, um zu zeigen, stack-trace. Manchmal ist es genug, um check out die log-Datei, wo die ganzen Ausnahmen sind gedruckt. BTW ich persönlich brach einige geschützte Anwendung (für sport nur Interesse) und sah, dass Sie verwendet dieser trick zusätzlich zu der Verschleierung.
    InformationsquelleAutor AlexR
  5. 1

    Vielleicht wollen Sie fangen eine Ausnahme und werfen eine neue, nicht Kapseln von Ihrer bisherigen Ausnahme. getStackTrace von den Gefangenen ein, und setzen Sie den stackTrace für die neue.

    Dies würde auch funktionieren, wenn man ein singleton Ausnahme, einmal instanziiert wie:

    private static Exception theException = new MyException();

    geworfen wird mehrere Male. Dies würde den stackTrack zu etwas, das in Bezug auf die Ausnahme gefangen werden, ohne die Notwendigkeit zu teuer erstellen Sie eine neue Ausnahme, jedes mal. Ich denke, das ist, wie Scala tut Ihr continue-und break-Konstrukte.

    try {
    ....
} catch (OtherException oe) {
    theException.fillStackTrace(oe.getStackTrace());
    theException.setMessage(...); //etc
    throw theException;
}

    Statische Ausnahmen kann schwierig sein, wenn Sie geworfen werden können, mehrere Zeiten gleichzeitig (D. H. in threads)

    • Am besten, dies ist der code obfuscation. Ausnahmen sollten behandelt werden, als wären Sie unveränderlich. Die OtherException sollte einfach wickeln wie die Ursache einer neuen Ausnahme. Scala verwendet, leeren stack-traces für nicht-lokale Flusskontrolle als ein weiteres Beispiel für den gleichen Grund erklärt in meinem post, aber nicht so.
    • Ausnahmen sind nicht unveränderlich, so dass Sie wirklich nicht wollen, sagen wir, weisen Sie eine statische.
    InformationsquelleAutor Jaime Garza
  6. 1

    Einen ähnlichen Frage liefert die Antwort.

    Gemäß der JLS standardmäßig ein stacktrace ist ausgefüllt, wenn die Ausnahme ist, instanziiert. Jedoch, es gibt Zeiten, möchten Sie vielleicht, um die "reset" - Stapel, um etwas mehr nützlich-Position, wenn Sie erneute auslösen.

    Erlauben, diese Funktionalität haben wir fillInStackTrace()

    BEARBEITEN

    Gut, heute habe ich gelernt, die Java-standard-Bibliothek Spezifikation entfernt wurde von der JLS nach der revision 1. Wie das Vorwort zur zweiten Auflage Staaten:

    The specifications of the libraries are now far too large to fit into this volume, and
they continue to evolve. Consequently, API specifications have been removed from
this book. The library specifications can be found on the Web; this specification
now concentrates solely on the Java programming language proper.

    Als solche, die wir wirklich brauchen, um einen genaueren Blick auf die javadoc, um dies herauszufinden. Die API ist hier überraschend Locker. Alle relevanten Teile sind aus dem Kopf, in dem es heißt:

    Instances of two subclasses, Error and Exception, are conventionally used to indicate   
that exceptional situations have occurred. Typically, these instances are freshly 
created in the context of the exceptional situation so as to include relevant 
information (such as stack trace data).

    Und java.lang.Throwable.printStackTrace() ist 

    Prints this throwable and its backtrace to the standard error stream.

    Meine überzeugung ist, dass dies zu ermöglichen VM implementors zu bieten, was die meisten performante/passende Umsetzung für Ihren Kontext. Mit diesem Kontext, dass die explizite fillInStackTrace() public macht sogar noch mehr Sinn.

    Standardmäßig werden die Virtuellen Maschinen bietet Sie mit die beste Mühe backtrace Lage. Machen fillInStackTrace() public ermöglicht es Entwicklern, verfeinern Sie weiter.

    --

    einer Endredaktion 🙂

    Ich es geschafft, die Spur eine Verbleibende link auf die relevanten bits der JLS Erste Ausgabe und ich würde gerne anbieten einen weiteren Grund, weshalb die Methode ist öffentlich. Es ist für besser oder schlechter, eine gemeinsame Erklärung in Java.

    Es war immer so.

    • Können Sie uns erklären, welche zusätzlichen Informationen hinter deinem link über jtahlborn Antwort auf diese Frage? Hat die JLS Staat, der nichts über die Verwendung von fillInStackTrace?
    InformationsquelleAutor Adam Malter
Schreibe einen Kommentar