1. Übersicht
In den Sprachen C und C++ gibt es den 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. Grammatik
In Java wurde das Schlüsselwort „assertion“ ab JAVA SE 1.4 eingeführt. Um Fehler zu vermeiden, die durch die Verwendung des Schlüsselworts „assertion“ in älteren Versionen von Java-Code verursacht werden, aktiviert Java bei der Ausführung standardmäßig keine Assertionsprüfung (zu diesem Zeitpunkt ist dies bei allen Assertion-Anweisungen der Fall). ignoriert werden!), wenn Sie die Assertionsprüfung aktivieren möchten, müssen Sie sie mit dem Schalter -enableassertions oder -ea einschalten.
Die Syntax des Schlüsselworts „asset“ ist sehr einfach und hat zwei Verwendungszwecke:
1. Bestätigen Sie <booleschen Ausdruck>
Wenn <boolescher Ausdruck> wahr ist, wird die Programmausführung fortgesetzt.
Bei „false“ löst das Programm einen AssertionError aus und beendet die Ausführung.
2. behaupten <boolescher Ausdruck>: <Fehlermeldungsausdruck>
Wenn <boolescher Ausdruck> wahr ist, wird die Programmausführung fortgesetzt.
Wenn es falsch ist, löst das Programm java.lang.AssertionError aus und gibt <error message expression> ein.
3. Anwendungsbeispiele
Zur Veranschaulichung der Verwendung wird im Folgenden ein Beispiel gegeben:
Kopieren Sie den Codecode wie folgt:
öffentliche Klasse AssertFoo {
public static void main(String args[]) {
//Das Ergebnis von Behauptung 1 ist wahr, dann wird die Ausführung fortgesetzt.
behaupten wahr;
System.out.println("Es gibt kein Problem mit Behauptung 1, Los!");
System.out.println("/n----/n");
//Das Ergebnis von Behauptung 2 ist falsch und das Programm wird beendet
affirm false: „Assertion fehlgeschlagen, die Informationen dieses Ausdrucks werden ausgegeben, wenn eine Ausnahme ausgelöst wird!“;
System.out.println("Es gibt kein Problem mit Behauptung 2, Los!");
}
}
Speichern Sie den Code unter C:/AssertFoo.java, führen Sie ihn dann wie folgt aus und sehen Sie sich die Konsolenausgabe an:
1. Programm kompilieren:
C:/>javac AssertFoo.java
2. Das Programm wird standardmäßig ausgeführt, ohne den Schalter -ea zu aktivieren:
C:/>java AssertFoo
Behauptung 1 ist in Ordnung, Los!
-------------------
Behauptung 2 ist kein Problem, Los!
3. Schalten Sie den Schalter -ea ein und führen Sie das Programm aus:
C:/>java -ea AssertFoo
Behauptung 1 ist in Ordnung, los!
-------------------
Ausnahme im Thread „main“ java.lang.AssertionError: Assertion fehlgeschlagen, die Informationen dieses Ausdrucks werden übernommen
Wird ausgegeben, wenn eine Ausnahme ausgelöst wird!
bei AssertFoo.main(AssertFoo.java:10)
4. Falle
Das Schlüsselwort „asser“ ist einfach zu verwenden, aber die Verwendung von „assert“ führt Sie oft in eine immer tiefere Falle. Sollte vermieden werden. Nach Recherchen fasste der Autor die folgenden Gründe zusammen:
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 beim Testen und Debuggen des Programms verwendet werden. Wenn Sie jedoch versehentlich „assert“ verwenden, um den Geschäftsprozess des zu steuern Das Entfernen des Assert-Schlüsselworts nach Abschluss bedeutet, dass die normale Logik des Programms geändert wird.
3. Wenn die Assertion-Behauptung 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 zur Behauptung
Da „asser“ für das Debuggen von Testprogrammen und nicht für die Verwendung in formalen Produktionsumgebungen gedacht ist, sollten Sie darüber nachdenken, JUint besser zu testen, um seine Funktion zu ersetzen. JUint bietet noch mehr Schlüsselfunktionen als „asser“. 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 einen Behauptungsstil zu verwenden. Es ist sehr wahrscheinlich, dass eine große Anzahl von Behauptungen verwendet wird, aber der Autor kann sich nicht sicher sein, bevor er sich das ansieht Quellcode.
Wenn es sich um einen einfachen Test während der Entwicklungsphase handelt, ist junit ein praktisches und leistungsstarkes Tool. Es gibt keinen Grund, es nicht beim Schreiben Ihrer eigenen Aussagen zu verwenden.
=============================================== ==========
Kommentar:
Erstens kann es 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 verwendet werden.
Assert eignet sich hauptsächlich für Basisklassen, Framework-Klassen, Schnittstellenklassen, Kerncodeklassen und Toolklassen. 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 schnellen Sortieralgorithmus erstellen
Kopieren Sie den Codecode wie folgt:
öffentliche statische Liste<int> quickSort(List<int> list){
Behauptungsliste != null;
//Bewerben Sie sich um temporären Platz
//Sortieren starten
for(int i : list){
//
}
}
Wenn in diesem Fall die Richtigkeit der eingehenden Parameter nicht überprüft wird, wird ein unerklärlicher Nullzeigerfehler ausgegeben. 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.
Bei Fehlern gilt, dass Sie genau wissen, um welchen Fehler es sich handelt, und dass Sie und Ihr Anrufer vereinbart haben, dass Ihr Anrufer Fehler beseitigen oder nach Fehlern suchen 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 die erzwungene Typkonvertierung seltener erfolgt, sodass nicht häufig überprüft werden muss, ob der Typ des Zeigers korrekt ist und ob der Zeiger wie bei C leer ist. 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.
Die Verwendung von „assert well“ kann jedoch 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 Erkennung eigener Logikfehler zu ermöglichen, ohne die Effizienz des Programms zu beeinträchtigen. Die von „asser“ 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.