Detaillierte Erläuterung des Schlüsselworts „asset' in Java-Traps-javaLernprogramm-php.cn

1. Übersicht

In den Sprachen C und C++ gibt es einen Assert-Schlüssel, der Assertion bedeutet.
In Java gibt es auch das Schlüsselwort „assertion“, was „Assertion“ bedeutet. Die Verwendung und Bedeutung sind ähnlich.

2. Syntax

In Java wurde das Schlüsselwort „asser“ ab JAVA SE 1.4 eingeführt. Um Fehler zu vermeiden, die durch die Verwendung des Schlüsselworts „asser“ in älteren Versionen von Java-Code verursacht werden, wird Java standardmäßig ausgeführt ist die Assertionsprüfung nicht aktiviert (zu diesem Zeitpunkt werden alle Assertionsanweisungen ignoriert!). Wenn Sie die Assertionsprüfung aktivieren möchten, müssen Sie den Schalter -enableassertions oder -ea verwenden, um sie zu aktivieren.

Die Syntax des Schlüsselworts „asset“ ist sehr einfach und hat zwei Verwendungszwecke:

1. „assertieren“
Wenn
Wenn es falsch ist, löst das Programm AssertionError aus und beendet die Ausführung.

2. Assert
Wenn wahr ist, setzt das Programm die Ausführung fort.
Wenn es falsch ist, löst das Programm java.lang.AssertionError aus und gibt ein.

3. Anwendungsbeispiel

Das Folgende ist ein Beispiel zur Veranschaulichung der Verwendung:

public class AssertFoo {
    public static void main(String args[]) {
        //断言1结果为true，则继续往下执行
        assert true;
        System.out.println("断言1没有问题，Go！");

        System.out.println("\n-----------------\n");

        //断言2结果为false,程序终止
        assert false : "断言失败，此表达式的信息将会在抛出异常的时候输出！";
        System.out.println("断言2没有问题，Go！");
    }
}

Nach dem Login kopieren

Speichern Sie den Code unter C:\AssertFoo.java, führen Sie ihn dann wie folgt aus und sehen Sie sich die Konsolenausgabe an:

1. Kompilieren Sie das Programm:
C:>javac AssertFoo.java

2. Das Programm wird standardmäßig ohne den Schalter -ea ausgeführt:
C:>java AssertFoo
Es gibt kein Problem mit Behauptung 1, Go!

-----------------

Es gibt kein Problem mit Behauptung 2, Go!

3. Schalten Sie den Schalter -ea ein und führen Sie das Programm aus:
C:>java -ea AssertFoo
Es gibt kein Problem mit Behauptung 1, Go!

-----------------

Ausnahme im Thread „main“ java.lang.AssertionError: Assertion fehlgeschlagen, die Informationen dieses Ausdrucks werden angezeigt
Wird ausgegeben, wenn eine Ausnahme ausgelöst wird!
bei AssertFoo.main(AssertFoo.java:10)

4. Fallen

Das Schlüsselwort „assert“ ist einfach zu verwenden, aber die Verwendung von „assertion“ führt oft dazu, dass man immer tiefer in die Tiefe gerät fangen. . Sollte vermieden werden. Nach der Recherche hat der Autor die folgenden Gründe zusammengefasst:

1. Das Schlüsselwort „assertion“ muss zur Laufzeit explizit aktiviert werden, damit es wirksam wird, andernfalls ist Ihre Behauptung bedeutungslos. Derzeit ist die Assertionsprüfungsfunktion -ea in gängigen Java-IDE-Tools standardmäßig nicht aktiviert. Dies bedeutet, dass beim Debuggen und Ausführen einige Probleme auftreten, wenn Sie IDE-Tools zum Codieren verwenden. Darüber hinaus wird bei Java-Webanwendungen der Programmcode im Container bereitgestellt und Sie können die Ausführung des Programms nicht direkt steuern. Wenn Sie den Schalter -ea aktivieren müssen, müssen Sie die laufenden Konfigurationsparameter des Webcontainers ändern. Dies bringt große Unannehmlichkeiten bei der Transplantation und Bereitstellung von Programmen mit sich.

2. Die Verwendung von „asser“ anstelle von „if“ ist die zweite Falle. Die Beurteilung von „asser“ ähnelt der von „if“-Anweisungen, die Funktionen der beiden unterscheiden sich jedoch wesentlich: Das Schlüsselwort „asset“ soll zum Testen und Debuggen des Programms verwendet werden. Wenn Sie jedoch versehentlich „assertion“ verwenden, um den Geschäftsprozess des zu steuern Das Entfernen des Schlüsselworts „asset“ nach Abschluss bedeutet, dass die normale Logik des Programms geändert wird.

3. Wenn die Assertion fehlschlägt, wird das Programm beendet. Dies würde in einer Produktionsumgebung niemals toleriert werden. Mögliche Fehler im Programm werden im Allgemeinen durch Ausnahmebehandlung behoben. Die Verwendung von Behauptungen ist jedoch sehr gefährlich. Sobald dies fehlschlägt, bleibt das System hängen.

5. Gedanken zu Assert

Da Assert zum Debuggen von Testprogrammen und nicht in formalen Produktionsumgebungen verwendet wird, sollten wir darüber nachdenken, JUint besser zu testen, um es zu ersetzen Die von JUint bereitgestellten Codes sind sogar besser als Assert. Natürlich können Debugging und Tests über das IDE-Debug durchgeführt werden. Aus dieser Sicht ist die Zukunft von Assert düster.

Daher sollten Sie die Verwendung des Schlüsselworts „asset“ in Java vermeiden, es sei denn, eines Tages unterstützt Java standardmäßig den Schalter „-ea“, dann können Sie darüber nachdenken. Vergleichen Sie, wie viel Nutzen und wie viel Ärger Ihnen die Behauptung bringen kann. Nach diesem Prinzip entscheiden wir, ob wir sie verwenden.

========================================== == ================
Kommentar:
Andererseits scheint der Beurteilungsprozess in einigen Open-Source-Komponenten wie Validator und Junit das zu verwenden Behauptungsstil, der sehr ist Es ist möglich, dass eine große Anzahl von Behauptungen verwendet wird, aber ich kann nicht sicher sein, ohne einen Blick auf den Quellcode zu werfen.
Wenn es sich um einen einfachen Test in der Entwicklungsphase handelt, ist junit ein praktisches und leistungsstarkes Tool. Es gibt keinen Grund, Aussagen selbst zu schreiben und es nicht zu verwenden.

========================================== == ================
Kommentar:
kann zuerst im Unit-Test-Code verwendet werden. Junit ist sehr aufdringlich. Wenn eine große Menge Code im gesamten Projekt Junit verwendet, ist es schwierig, ihn zu entfernen oder ein anderes Framework auszuwählen. Wenn viele Unit-Test-Codes vorhanden sind und Sie diese Unit-Test-Fälle wiederverwenden möchten, sollten Sie Assert anstelle von Junit wählen, um die Verwendung anderer Unit-Test-Frameworks wie TestNG zu erleichtern. Aus dem gleichen Grund sollte Junit überhaupt nicht im formalen Funktionscode vorkommen und Assert sollte hauptsächlich für Basisklassen, Framework-Klassen, Schnittstellenklassen, Kerncodeklassen und Tool-Klassen verwendet werden. Mit anderen Worten, es ist notwendig, es zu verwenden, wenn der Aufrufer Ihres Codes Geschäftscode ist, der von einem anderen Programmierer oder einem anderen Subsystem geschrieben wurde. Wenn Sie beispielsweise einen Schnellsortierungsalgorithmus

erstellen, wird in diesem Fall ein unerklärlicher Nullzeigerfehler ausgegeben, wenn Sie die Richtigkeit der übergebenen Parameter nicht überprüfen. Ihre Aufrufer kennen möglicherweise nicht die Details Ihres Codes und das Debuggen eines Nullzeigerfehlers tief im System ist Zeitverschwendung. Sie sollten Ihrem Anrufer direkt und deutlich mitteilen, dass ein Problem mit den übergebenen Parametern vorliegt. Andernfalls wird er vermuten, dass Ihr Code einen Fehler aufweist. Die Verwendung von „assert“ kann verhindern, dass sich zwei Programmierer gegenseitig die Schuld für Probleme mit dem von ihnen geschriebenen Code geben.

public static List<int> quickSort(List<int> list){
  assert list != null;
  // 申请临时空间
  //开始排序
  for(int i : list){
      //
  }
}

Nach dem Login kopieren

Bei Fehlern gilt die Behauptung, dass Sie den konkreten Fehler kennen und Sie und Ihr Anrufer vereinbart haben, dass Ihr Anrufer den Fehler beseitigen oder prüfen soll. Sie teilen es Ihrem Anrufer über eine Behauptung mit. „assertion“ gilt nicht für Fehler, die durch externe Systeme verursacht werden, wie z. B. Fehler in Benutzereingabedaten oder Formatfehler in einer externen Datei. Diese Fehler werden nicht von Ihrem Aufrufer, sondern vom Benutzer verursacht und stellen nicht einmal Ausnahmen dar, da Eingabefehler und Dateiformatfehler häufig vorkommen und diese Fehler vom Geschäftscode überprüft werden sollten.

assert eignet sich besser für häufig aufgerufene Basisklassen, Framework-Code, Tool-Klassen, Kerncode und Schnittstellencode. Aus diesem Grund wird es zur Laufzeit entfernt. Der Testcode sollte den Parameter -ea während der Testphase aktivieren, um ein sorgfältiges Testen des Kerncodes tief im System zu ermöglichen.

Der Grund, warum Java „Assert“ seltener verwendet, liegt darin, dass Java über ein sehr vollständiges OO-System verfügt und eine erzwungene Typkonvertierung seltener erfolgt, sodass nicht häufig überprüft werden muss, ob der Typ des Zeigers korrekt ist und ob die Zeiger ist leer wie C. . Gleichzeitig verwaltet Java Speicher oder Puffer selten direkt, sodass nicht häufig überprüft werden muss, ob der eingehende Puffer leer ist oder die Grenze überschritten hat.

Aber die Verwendung von „assertion well“ kann dazu beitragen, die Korrektheit des Framework-Codes zu verbessern und die Debugging-Zeit der Benutzer des Framework-Codes zu verkürzen.

========================================== == ===================
Kommentar: Der Zweck von
assert besteht darin, Programmierern die einfache Entdeckung ihrer eigenen Logikfehler zu ermöglichen, ohne die Effizienz des zu beeinträchtigen Programm. Die von Assertion gefundenen Fehler sollten überhaupt nicht auftreten und können nicht durch Ausnahmen ersetzt werden. Ausnahmen werden vom System zugelassen oder sind „Fehler“, die vom System nicht kontrolliert werden können. Sie sind keine logischen Probleme des Programmierers.

Assert sollte während der Entwicklung aktiviert und nach der Veröffentlichung deaktiviert werden.

Ausführlichere Erklärungen zum Assert-Schlüsselwort in Java-Traps und verwandte Artikel finden Sie auf der chinesischen PHP-Website!