Java >> Java tutorial >  >> Tag >> assert

Skal du hævde ikke null med assert-sætningen i produktionskoden?

assert

Brug Objects.requireNonNull(Object) for det.

Kontrollerer, at den angivne objektreference ikke er nul. Denne metode er primært designet til at udføre parametervalidering i metoder og konstruktører, [...]

I dit tilfælde ville det være:

public void useObject(CustomObject customObject) {
    object = customObject.getObject();
    Objects.requireNonNull(object); // throws NPE if object is null
    // do stuff with object
}

Denne funktion er lavet til det, du vil gøre:marker eksplicit, hvad der ikke skal være null . Fordelen er, at du finder null -værdier lige der, hvor de ikke burde forekomme. Du vil have mindre problemer med at fejlfinde problemer forårsaget af null s, der passeres et sted, hvor de ikke burde være.

En anden fordel er fleksibiliteten ved brug af denne funktion i modsætning til assert . Mens assert er et nøgleord til kontrol af en boolesk værdi, Objects.requireNonNull(Object) er en funktion og kan meget nemmere indlejres i kode.

Foo foo = Objects.requireNonNull(service.fetchFoo());

// you cannot write it in one line.
Bar bar = service.fetchBar();
assert bar != null;

service.foo(Objects.requireNonNull(service.getBar()));

// you cannot write it in one line.
Bar bar = service.getBar();
assert bar != null;
service.foo(bar);

Husk at Objects.requireNonNull(Object) er kun for null -kontrol mens assert er til generelle påstande. Så assert har forskellige formål:primært test. Det skal være aktiveret, så du kan aktivere det til test og deaktivere det i produktionen. Brug den til at adskille test-kun-test fra test, eller rettere kontrol, der også er beregnet til produktionskode.


Det vigtigste at huske om påstande er, at de kan deaktiveres, så antag aldrig, at de bliver udført.

For bagudkompatibilitet deaktiverer JVM som standard påstandsvalidering. De skal udtrykkeligt aktiveres ved at bruge enten kommandolinjeargumentet -enableassertions eller dets forkortelse -ea:

java -ea com.whatever.assertion.Assertion

Så det er ikke en god praksis at stole på dem.

Da påstande ikke er aktiveret som standard, kan du aldrig antage, at de vil blive udført, når de bruges i koden. Så du bør altid tjekke for nul-værdier og tomme valgfrie funktioner, undgå at bruge påstande til at kontrollere input i en offentlig metode og i stedet bruge en umarkeret undtagelse... Udfør generelt alle kontroller, som om påstanden ikke var der.


Det du får at vide er helt sikkert en åbenlys løgn. Her er hvorfor.

Påstande er deaktiveret som standard, hvis du bare udfører selvstændigt jvm. Når de er deaktiveret, har de nul fodaftryk, og de vil derfor ikke påvirke din produktionsapplikation. Men de er sandsynligvis dine bedste venner, når du udvikler og tester din kode, og de fleste testrammeløbere aktiverer påstande (JUnit gør det), så din påstandskode udføres, når du kører dine enhedstests, hvilket hjælper dig med at opdage eventuelle potentielle fejl tidligere (f.eks. du kan tilføje påstande til nogle forretningslogiske grænsekontrol, og det vil hjælpe med at opdage noget kode, der bruger upassende værdier).

Når det er sagt, som det andet svar antyder, kan du af netop den grund (de er ikke altid aktiveret) ikke stole på påstande for at udføre nogle vitale kontroller eller (især!) opretholde en tilstand.

For et interessant eksempel på, hvordan du kan bruge asserts, kig her - i slutningen af ​​filen er der en metode singleThreadedAccess() som kaldes fra assert-erklæringen på linje 201 og er der for at fange enhver potentiel multithreaded-adgang i tests.


Java tag