Java påstander (påstand uttalelse)

I denne opplæringen vil vi lære om Java-påstanden (Java-påstander) ved hjelp av eksempler.

Påstander i Java hjelper til med å oppdage feil ved å teste kode vi antar å være sanne.

En påstand gjøres ved hjelp av assertnøkkelordet.

Dens syntaks er:

 assert condition;

Her conditioner et boolsk uttrykk som vi antar er sant når programmet kjøres.

Aktivere påstander

Påstander er som standard deaktivert og ignorert ved kjøretid.

For å aktivere påstander bruker vi:

 java -ea:arguments

ELLER

 java -enableassertions:arguments

Når påstander er aktivert og tilstanden er true, kjøres programmet normalt.

Men hvis tilstanden evalueres til falsemens påstander er aktivert, kaster JVM en AssertionError, og programmet stopper umiddelbart.

Eksempel 1: Java-påstand

 class Main ( public static void main(String args()) ( String() weekends = ("Friday", "Saturday", "Sunday"); assert weekends.length == 2; System.out.println("There are " + weekends.length + " weekends in a week"); ) )

Produksjon

 Det er 3 helger i løpet av en uke

Vi får utdataene ovenfor fordi dette programmet ikke har noen kompileringsfeil, og påstander er som standard deaktivert.

Etter at påstander er aktivert, får vi følgende utdata:

 Unntak i tråden "hoved" java.lang.AssertionError

En annen form for påstand

 assert condition : expression;

I denne formen for påstandssetning sendes et uttrykk til konstruktøren av AssertionErrorobjektet. Dette uttrykket har en verdi som vises som feilmeldingens detaljmelding hvis tilstanden er false.

Den detaljerte meldingen brukes til å fange opp og overføre informasjonen om påstanden om å ikke feilsøke problemet.

Eksempel 2: Java-påstand med uttrykkeksempel

 class Main ( public static void main(String args()) ( String() weekends = ("Friday", "Saturday", "Sunday"); assert weekends.length==2 : "There are only 2 weekends in a week"; System.out.println("There are " + weekends.length + " weekends in a week"); ) )

Produksjon

 Unntak i tråden "hoved" java.lang.AssertionError: Det er bare to helger i løpet av en uke

Som vi ser fra eksemplet ovenfor, blir uttrykket overført til konstruktøren av AssertionErrorobjektet. Hvis vår antagelse er falseog påstander er aktivert, kastes et unntak med en passende melding.

Denne meldingen hjelper deg med å diagnostisere og fikse feilen som førte til at påstanden mislyktes.

Aktiverer påstand for spesifikke klasser og pakker

Hvis vi ikke gir noen argumenter for påstanden kommandolinjebrytere,

 java -ea

Dette muliggjør påstander i alle klasser unntatt systemklasser.

Vi kan også aktivere påstand for spesifikke klasser og pakker ved hjelp av argumenter. Argumentene som kan gis til disse kommandolinjebryterne er:

Aktiver påstand i klassenavn

For å aktivere påstand for alle klasser i vårt hovedprogram,

 java -ea Main

For å aktivere bare en klasse,

 java -ea:AnimalClass Main

Dette gjør at påstanden i bare AnimalClassi Mainprogrammet.

Aktiver påstand i pakkenavn

For å aktivere påstander for bare pakken com.animalog dens underpakker,

 java -ea:com.animal… Main

Aktiver påstand i ikke-navngitte pakker

For å aktivere påstand i ikke-navngitte pakker (når vi ikke bruker en pakkeerklæring) i gjeldende arbeidskatalog.

 java -ea:… Main

Aktiver påstand i systemklasser

For å aktivere påstand i systemklasser bruker vi en annen kommandolinjebryter:

 java -esa:arguments

ELLER

 java -enablesystemassertions:arguments

Argumentene som kan gis til disse bryterne er de samme.

Deaktivering av påstander

For å deaktivere påstander bruker vi:

 java -da arguments

ELLER

 java -disableassertions arguments

To disable assertion in system classes, we use:

 java -dsa:arguments

OR

 java -disablesystemassertions:arguments

The arguments that can be passed while disabling assertions are the same as while enabling them.

Advantages of Assertion

  1. Quick and efficient for detecting and correcting bugs.
  2. Assertion checks are done only during development and testing. They are automatically removed in the production code at runtime so that it won’t slow the execution of the program.
  3. It helps remove boilerplate code and make code more readable.
  4. Refactors and optimizes code with increased confidence that it functions correctly.

When to use Assertions

1. Unreachable codes

Unreachable codes are codes that do not execute when we try to run the program. Use assertions to make sure unreachable codes are actually unreachable.

Let’s take an example.

 void unreachableCodeMethod() ( System.out.println("Reachable code"); return; // Unreachable code System.out.println("Unreachable code"); assert false; )

Let’s take another example of a switch statement without a default case.

 switch (dayOfWeek) ( case "Sunday": System.out.println("It’s Sunday!"); break; case "Monday": System.out.println("It’s Monday!"); break; case "Tuesday": System.out.println("It’s Tuesday!"); break; case "Wednesday": System.out.println("It’s Wednesday!"); break; case "Thursday": System.out.println("It’s Thursday!"); break; case "Friday": System.out.println("It’s Friday!"); break; case "Saturday": System.out.println("It’s Saturday!"); break; )

The above switch statement indicates that the days of the week can be only one of the above 7 values. Having no default case means that the programmer believes that one of these cases will always be executed.

However, there might be some cases that have not yet been considered where the assumption is actually false.

This assumption should be checked using an assertion to make sure that the default switch case is not reached.

 default: assert false: dayofWeek + " is invalid day";

If dayOfWeek has a value other than the valid days, an AssertionError is thrown.

2. Documenting assumptions

To document their underlying assumptions, many programmers use comments. Let’s take an example.

 if (i % 2 == 0) (… ) else ( // We know (i % 2 == 1)… )

Use assertions instead.

Comments can get out-of-date and out-of-sync as the program grows. However, we will be forced to update the assert statements; otherwise, they might fail for valid conditions too.

 if (i % 2 == 0) (… ) else ( assert i % 2 == 1 : i;… )

When not to use Assertions

1. Argument checking in public methods

Arguments in public methods may be provided by the user.

So, if an assertion is used to check these arguments, the conditions may fail and result in AssertionError.

Instead of using assertions, let it result in the appropriate runtime exceptions and handle these exceptions.

2. To evaluate expressions that affect the program operation

Do not call methods or evaluate exceptions that can later affect the program operation in assertion conditions.

Let us take an example of a list weekdays which contains the names of all the days in a week.

  ArrayList weekdays = new ArrayList(Arrays.asList("Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday" )); ArrayList weekends= new ArrayList(Arrays.asList("Sunday", "Saturday" )); assert weekdays.removeAll(weekends);

Here, we are trying to remove elements Saturday and Sunday from the ArrayList weekdays.

Hvis påstanden er aktivert, fungerer programmet bra. Imidlertid, hvis påstander er deaktivert, fjernes ikke elementene fra listen. Dette kan føre til programfeil.

Tildel i stedet resultatet til en variabel, og bruk deretter den variabelen for påstand.

 ArrayList weekdays = new ArrayList(Arrays.asList("Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday" )); ArrayList weekends= new ArrayList(Arrays.asList("Sunday", "Saturday" )); boolean weekendsRemoved = weekdays.removeAll(weekends); assert weekendsRemoved;

På denne måten kan vi sikre at alle helgene blir fjernet fra ukedagene uavhengig av påstanden som er aktivert eller deaktivert. Som et resultat påvirker det ikke programdriften i fremtiden.

Interessante artikler...