Java Behauptungen zu wenig genutzt

Question

Ich frage mich, warum das assert Schlüsselwort so in Java zu wenig genutzt wird? Ich habe fast nie verwendet gesehen, aber ich denke, sie sind eine großartige Idee. Ich sicherlich viel die Kürze bevorzugen:

assert param != null : "Param cannot be null";

auf die Ausführlichkeit von:

if (param == null) {
    throw new IllegalArgumentException("Param cannot be null");
}

Mein Verdacht ist, dass sie aufgrund

zu wenig genutzt sind

• Sie kamen relativ spät (Java 1.4), mit dem hatte viele Menschen Zeit bereits ihre Java-Programmierstil / Gewohnheit
etabliert
• Sie werden zur Laufzeit standardmäßig
ausgeschaltet

Answer 1

Behauptungen sind in der Theorie, für die Prüfung Invarianten , Annahmen, die starken <> muss wahr sein, damit der Code ordnungsgemäß abzuschließen.

Das gezeigte Beispiel ist Prüfung für gültige Eingabe, die keine typische Verwendung für eine Behauptung ist, weil es ist, in der Regel, Benutzer geliefert wird.

Assertions sind im Allgemeinen nicht in Produktionscode verwendet, weil es ein Overhead, und es wird angenommen, dass Situationen, in denen die Invarianten als Codierungsfehler bei der Entwicklung und Erprobung gefangen wurden fail.

Ihr Punkt über sie „spät“ zu Java kommt, ist auch ein Grund, warum sie mehr sind nicht weit zu sehen.

Auch Testeinheit Frameworks ermöglicht einen Teil der Notwendigkeit programmatische Aussagen zu dem Code getestet extern zu sein.

Answer 2

Es ist ein Missbrauch von Behauptungen, sie zu benutzen Benutzereingabe zu testen. ein IllegalArgumentException auf ungültige Eingabe Werfen ist richtig, da es die anrufende Methode erlaubt die Ausnahme abzufangen, um den Fehler anzuzeigen, und zu tun, was es braucht, um (wieder eingabe fragen, beenden, was auch immer).

Wenn das Verfahren eine private Methode innerhalb einer Ihrer Klassen ist, ist die Behauptung, in Ordnung, weil Sie gerade versuchen, sicherzustellen, dass Sie es ein Null-Argument nicht zufällig sind vorbei. Sie testen, mit Behauptungen auf, und wenn Sie die Behauptung alle Pfade durch und nicht ausgelöst getestet haben, können Sie sie ausschalten, so dass Sie keine Ressourcen auf sie verschwenden. Sie sind auch nur als Kommentare. Ein assert zu Beginn eines Verfahrens ist eine gute Dokumentation zu Maintainer, dass sie bestimmte Voraussetzungen werden folgende sollte, und ein assert am Ende mit einem Nachbedingung Dokumente, was die Methode tun sollte. Sie können ebenso nützlich wie Kommentare sein; moreso, weil mit Behauptungen auf, sie tatsächlich testen, was sie dokumentieren.

Assertions sind zum Testen / Debuggen, nicht Fehlerprüfung, weshalb sie standardmäßig deaktiviert sind. Zu entmutigen Menschen von Behauptungen mit Benutzereingaben zu validieren

Answer 3

Programmierung mit Assertions

  

Standardmäßig Behauptungen sind zur Laufzeit deaktiviert. Zwei Befehlszeilenoptionen können Sie selektiv aktivieren oder deaktivieren Behauptungen.

Das bedeutet, dass, wenn Sie nicht die vollständige Kontrolle über die Laufzeitumgebung haben, können Sie nicht garantieren, dass die Behauptung Code wird auch genannt werden. Assertions sollen in einer Testumgebung verwendet werden, nicht für die Produktion Code. Sie können keine Ausnahme mit Behauptungen Handhabung ersetzen, weil, wenn der Benutzer die Anwendung läuft mit Behauptungen deaktiviert (die default ), die alle Ihre Fehlerbehandlungscode verschwindet.

Answer 4

„Effective Java“, Joshua Bloch vorgeschlagen (in den „überprüft die Parameter für die Gültigkeit“ Thema), dass (Art wie eine einfache Regel zu übernehmen), für öffentliche Methoden werden wir die Argumente prüfen und notwendige Ausnahme auslösen, wenn gefunden ungültig, und für nicht-öffentliche Methoden (die nicht ausgesetzt sind und Sie als Anwender von ihnen sollten ihre Gültigkeit gewährleisten), können wir Behauptung stattdessen verwenden.

yc

Answer 5

@Don, sind Sie frustriert, dass Behauptung ist standardmäßig deaktiviert. Ich war auch, und so schrieb diese kleine javac-Plugin, das sie inlines (dh emittiert den Bytecode für if (!expr) throw Ex eher als dieser dummen assert Bytecode.

Wenn Sie umfassen fa.jar in Ihrem Classpath während Java-Code kompiliert, es wird seine Magie tun und dann sagen,

Note: %n assertions inlined.

http://smallwiki.unibe.ch/adriankuhn/javacompiler/forceassertions und alternativ auf github https://github.com/akuhn/javac

Answer 6

Ich bin mir nicht sicher, warum Sie sich die Mühe, behauptet zu schreiben und sie dann mit einem Standard zu ersetzen, wenn dann Bedingungsanweisung, warum nicht nur die Bedingungen, wie ifs in erster Linie schreiben?

Asserts sind ausschließlich zu Test, und sie haben zwei Nebenwirkungen: (! Weshalb Sie sie ausschalten können) Größere Binärdateien und reduzierte Performance, wenn aktiviert

Asserts sollten die Bedingungen nicht verwendet werden, zu überprüfen, weil das das Verhalten Ihrer Anwendung bedeutet, während der Laufzeit unterschiedlich ist, wenn behauptet aktiviert / deaktiviert - was ist ein Alptraum

Answer 7

Assertions nützlich sind, da sie:

• Fang Programmierfehler früh
• Dokumentcode mit dem Code

Denken Sie an sie als Code Selbstvalidierung. Wenn sie ausfallen sollte es bedeuten, dass Ihr Programm ist kaputt und muss aufhören. Immer sie einschalten, während das Gerät testen!

Der Pragmatische Programmierer sie sogar empfehlen, sie in der Produktion laufen zu lassen.

  

Lassen Sie Assertions Turned On

     

Mit Assertions für das Unmögliche verhindern.

Beachten Sie, dass Behauptungen AssertionError werfen, wenn sie versagen, so nicht fangen Ausnahme gefangen.

Answer 8

Assertions sind sehr begrenzt: Sie können nur boolean Bedingungen testen und Sie müssen jedes Mal den Code für eine sinnvolle Fehlermeldung schreiben. Vergleichen Sie dies mit JUnit assertEquals (), die eine nützlichen Fehlermeldung von den Eingängen zu erzeugen, ermöglicht und sogar zeigt die beiden Eingänge nebeneinander in der IDE in einem JUnit runner.

Sie können aber auch nicht für Behauptungen in jedem IDE suchen die ich bisher gesehen habe, aber jeder IDE kann für Methodenaufrufe suchen.

Answer 9

In der Tat kamen sie in Java 1.4

Ich denke, das Hauptproblem ist, dass, wenn Sie Code in einer Umgebung, wo Sie verwalten nicht direkt Jvm Optionen selbst wie in Eclipse oder J2EE-Server (in beiden Fällen ist es möglich, Jvm Optionen zu ändern, aber Sie müssen tief suchen finden, wo es) durchgeführt werden kann, ist es einfacher (ich meine es weniger Aufwand) zu verwenden, erfordert, wenn und Ausnahmen (oder schlimmer noch nichts zu verwenden).

Answer 10

Wie andere gesagt haben:. Behauptungen nicht geeignet sind für Benutzereingaben Validierung

Wenn Sie mit Ausführlichkeit betroffen sind, empfehle ich Ihnen, eine Bibliothek Besuche schrieb ich: https: // bitbucket .org / cowwoc / Anforderungen / . Es wird ermöglicht es Ihnen, diese Prüfungen mit sehr wenig Code zum Ausdruck bringen, und es wird auch die Fehlermeldung in Ihrem Namen generieren:

requireThat("name", value).isNotNull();

und wenn Sie sich mit Behauptungen bestehen, können Sie dies auch:

assertThat("name", value).isNotNull();

Die Ausgabe wird wie folgt aussehen:

java.lang.NullPointerException: name may not be null

Answer 11

tl; dr

• Ja, Verwendung Behauptungs Tests in der Produktion , wo es Sinn macht.
• Verwenden Sie andere Bibliotheken ( JUnit , AssertJ , hamcrest , etc.) anstatt die Anlage eingebaut in assert wenn Sie möchten.

Die meisten anderen Antworten auf dieser Seite die Maxime Push „Assertions sind in der Regel nicht in der Produktion Code verwendet“. Dies stimmt zwar in Produktivitäts-Apps wie zum Beispiel eines Textverarbeitungsprogramm oder Tabellenkalkulationsprogramm, in benutzerdefinierten Business-Anwendungen, wo Java so wird häufig verwendet, , Assertion-Tests in der Produktion ist äußerst nützlich und üblich.

Wie viele Maximen in der Welt der Programmierung, was in einem Kontext wahr beginnt wird verkannt und dann in einer anderen Kontext falsch angewandt.

Productivity Apps

Diese Maxime „Assertions sind im Allgemeinen nicht in Produktionscode verwendet“, obwohl gemeinsame, nicht korrekt ist.

Formalisierte Behauptungs Tests entstanden mit Apps wie ein Textverarbeitungsprogramm wie Microsoft Word oder eine Tabelle wie Microsoft Excel . Diese Anwendungen könnten eine Reihe von Tests Behauptung Behauptungen auf jeden Tastendruck gemacht durch den Benutzer aufrufen. Solche extreme Wiederholungsleistung stark beeinflusst. So wird nur die Beta-Versionen solcher Produkte in begrenzten Verteilung hatten Behauptungen aktiviert. So ist die Maxime.

Business-Apps

Im Gegensatz dazu ist in geschäftsorientierten Anwendungen für Dateneingabe, eine Datenbank oder andere Datenverarbeitung, ist die Verwendung von Assertion-Tests in der Produktion enorm nützlich. Der unbedeutende Hit auf Leistung macht es ganz praktisch -. Und gemeinsame

Test Geschäftsregeln

Überprüfen der Geschäftsregeln zur Laufzeit in der Produktion ist ganz vernünftig, und soll gefördert werden. Wenn zum Beispiel eine Rechnung einer oder mehr Positionen muss jederzeit, dann eine Behauptung Prüfung als die Anzahl der Rechnungspositionen schreiben größer als Null ist. Wenn ein Produktname mindestens 3 Zeichen oder mehr sein müssen, schreiben Sie eine Behauptung die Prüfung der Länge der Saite. Solche Tests haben keinen wesentlichen Einfluss auf die Leistung in der Produktion.

Laufzeitbedingungen

Wenn Ihre App bestimmte Bedingungen erwarten immer wahr zu sein, wenn Ihre Anwendung in der Produktion läuft, diese Erwartungen in Ihren Code als Behauptung Tests schreiben.

Wenn Sie diese Voraussetzungen vernünftigerweise gelegentlich erwarten scheitern, dann tun nicht Schreib Behauptung Tests. werfen vielleicht bestimmte Ausnahmen. Dann versuchen Sie, wo möglich zu erholen.

Sanity-Kontrollen

Sanity prüft zur Laufzeit in der Produktion ist auch ganz vernünftig, und sollte gefördert werden . ein paar beliebigen Bedingungen zu testen, die man nicht unwahr vorstellen konnte sein hat meinen Speck in unzähligen Situationen gerettet, wenn einige bizarren Geschehen aufgetreten.

Zum Beispiel testen, dass eine Nickel (0,05) auf den Cent Runden in einer Nickel ergab (0,05) in einer bestimmten Bibliothek half mir einen der ersten Menschen sind, um einen Floating-Point-Technologie Fehler zu entdecken, die von Apple ausgeliefert in ihrem Rosetta Bibliothek während des PowerPC-to-Intel-Übergangs. Ein solcher Fehler, die Öffentlichkeit zu erreichen wäre unmöglich schien. Aber erstaunlich war der Fehler die Bekanntmachung über die jeweiligen Hersteller entgangen, Transitive und Apple und die Early-Access-Entwickler-Tests auf dem Apple-Betas.

(By the way, sollte ich erwähnen, ... nie a href verwenden <= "https://en.wikipedia.org/wiki/Floating-point_arithmetic # Accuracy_problems "rel = "nofollow noreferrer"> Floating-Point-Leistungs-Verhältnis , verwenden Sie BigDecimal .)

Auswahl von Frameworks

Anstatt die eingebaute in assert Anlage verwenden, können Sie mit einer anderen Behauptung Rahmen zu betrachten. Sie haben mehrere Optionen, einschließlich:

• JUnit
  Siehe: org.junit.jupiter.api.Assertions .
• AssertJ
  Bekannt für seine glatte < a href = "https://en.wikipedia.org/wiki/Fluent_interface" rel = "nofollow noreferrer"> Fluent Interface .
• hamcrest
  in vielen Sprachen Gebraucht (Java , Python, Ruby, Swift, usw.).

oder Roll-your-own. Machen Sie eine kleine Klasse in Ihrem Projekt zu verwenden. So etwas wie dies.

package work.basil.example;

public class Assertions {
    static public void assertTrue ( Boolean booleanExpression , CharSequence message ) throws java.lang.AssertionError {
        if ( booleanExpression ) {
            // No code needed here.
        } else { // If booleanExpression is false rather than expected true, throw assertion error.
            // FIXME: Add logging.
            throw new java.lang.AssertionError( message.toString() );
        }
    }

}

Beispiel Nutzung:

Assertions.assertTrue( 
    localTime.isBefore( LocalTime.NOON ) , 
    "The time-of-day is too late, after noon: " + localTime + ". Message # 816a2a26-2b95-45fa-9b0a-5d10884d819d." 
) ;

Ihre Fragen

  

Sie kamen relativ spät (Java 1.4), mit dem hatten viele Menschen Zeit bereits ihre Java-Programmierstil / Gewohnheit etabliert

Ja, das ist ganz richtig. Viele Menschen wurden von der API enttäuscht, dass Sun / JCP für Behauptungsversuche entwickelt. Sein Design war im Vergleich zu dem bestehenden Bibliotheken glanzlos. So viele der neuen API ignoriert, und stecken mit bekannten Werkzeugen (3rd Party Tools oder Roll-your-own Mini-Bibliothek).

  

Sie werden zur Laufzeit standardmäßig deaktiviert, WARUM OH WARUM ??

In den ersten Jahren, bekam Java einen schlechten Ruf für schlechte Leistung Geschwindigkeit. Ironischerweise Java entwickelt schnell für die Leistung einer der besten Plattformen zu werden. Aber der schlechte Ruf hing wie ein stinkender Geruch um. So Sun war extrem vorsichtig bei allem, was könnte in irgendeiner Weise messbar die Leistung auswirken. Also in dieser Hinsicht machte es Sinn zu machen deaktivieren Behauptungs Testen den Standard.

Ein weiterer Grund standardmäßig deaktivieren könnte auf die Tatsache zurückzuführen war, dass die neue Behauptung Anlage in dem Hinzufügen, Sun das Wort assert entführt hatte. Dies war nicht ein zuvor reserviertes Schlüsselwort und erforderte eine der wenige Änderungen je nach der Java-Sprache gemacht. Der Methodenname assert wurde von vielen Bibliotheken und von vielen Entwicklern in ihrem eigenen Code verwendet. Seit einiger Diskussion dieser historischen Übergang, lesen Sie diese alte Dokumentation, Programmierung Mit Assertions .