Java-påstande (påstået erklæring)

I denne vejledning lærer vi om Java-påstanden (Java-påstande) ved hjælp af eksempler.

Påstande i Java hjælper med at opdage fejl ved at teste kode, vi antager at er sandt.

En påstand foretages ved hjælp af assertnøgleordet.

Dens syntaks er:

 assert condition;

Her conditioner et boolsk udtryk, som vi antager at være sandt, når programmet udføres.

Aktivering af påstande

Påstander er som standard deaktiveret og ignoreret ved kørsel.

For at aktivere påstande bruger vi:

 java -ea:arguments

ELLER

 java -enableassertions:arguments

Når påstande er aktiveret, og betingelsen er true, udføres programmet normalt.

Men hvis tilstanden evalueres til, falsemens påstande er aktiveret, kaster JVM en AssertionError, og programmet stopper med det samme.

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"); ) )

Produktion

 Der er 3 weekender om en uge

Vi får ovenstående output, fordi dette program ikke har kompileringsfejl, og som standard er påstande deaktiveret.

Efter aktivering af påstande får vi følgende output:

 Undtagelse i tråden "main" java.lang.AssertionError

En anden form for påstand

 assert condition : expression;

I denne form for påstand udsagn sendes et udtryk til konstruktøren af AssertionErrorobjektet. Dette udtryk har en værdi, der vises som fejlens detaljerede meddelelse, hvis betingelsen er false.

Den detaljerede besked bruges til at indfange og transmittere oplysningerne om påstanden om at fejle problemet.

Eksempel 2: Java-påstand med ekspressionseksempel

 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"); ) )

Produktion

 Undtagelse i tråden "main" java.lang.AssertionError: Der er kun 2 weekender om en uge

Som vi ser fra ovenstående eksempel, sendes udtrykket til konstruktøren af AssertionErrorobjektet. Hvis vores antagelse er, falseog påstande er aktiveret, kastes en undtagelse med en passende besked.

Denne meddelelse hjælper med at diagnosticere og rette den fejl, der fik påstanden til at mislykkes.

Aktivering af påstand for specifikke klasser og pakker

Hvis vi ikke giver argumenter til påstanden kommandolinjekontakter,

 java -ea

Dette muliggør påstande i alle klasser undtagen systemklasser.

Vi kan også aktivere påstand for specifikke klasser og pakker ved hjælp af argumenter. Argumenterne, der kan leveres til disse kommandolinjekontakter er:

Aktivér påstand i klassenavne

For at aktivere påstand for alle klasser i vores program Main,

 java -ea Main

For kun at aktivere en klasse,

 java -ea:AnimalClass Main

Dette gør det muligt påstand i kun det AnimalClassi Mainprogrammet.

Aktivér påstand i pakkenavne

For at aktivere påstande for kun pakken com.animalog dens underpakker,

 java -ea:com.animal… Main

Aktivér påstand i unavngivne pakker

For at aktivere påstand i unavngivne pakker (når vi ikke bruger en pakkeerklæring) i den aktuelle arbejdsmappe.

 java -ea:… Main

Aktivér påstand i systemklasser

For at aktivere påstand i systemklasser bruger vi en anden kommandolinjekontakt:

 java -esa:arguments

ELLER

 java -enablesystemassertions:arguments

Argumenterne, der kan leveres til disse switches, er de samme.

Deaktivering af påstande

For at deaktivere påstande bruger 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 aktiveret, fungerer programmet fint. Hvis påstande er deaktiveret, fjernes elementerne fra listen imidlertid ikke. Dette kan resultere i programfejl.

I stedet tildel resultatet til en variabel, og brug den variabel til 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åde kan vi sikre, at alle weekender fjernes fra hverdage, uanset påstanden er aktiveret eller deaktiveret. Som et resultat påvirker det ikke programmets drift i fremtiden.

Interessante artikler...