can any one explain the meaning of the statement "assertions let you test your assumptions during development but assertion code basically evaporates when the program is deployed leaving behind no overhead or debugging code to track down and remove"
Asked
Active
Viewed 688 times
3 Answers
4
EDIT: asserts should be used to detect coding errors rather than input errors.
They allow you to document the assumptions made in coding in a way which can be enforced when assertions are turned on. However these checks are ones which a well tested program shouldn't need on once released.
They are not suitable for validating user input as they are not designed to be friendly and assume the only way to fix a failed assertion is to fix the code (often killing or disabling the program in the process)
For validating user input, an if(!condition) friendly_user_message() is a better approach.
assertions allow you to perform expensive tests you want to be able to turn off for production cocde.
The JVM optimises out the assertions when you don't have them turned on.
EDIT: You may have a complex check you want to perform if asserts are on. Two ways you can do this are.
boolean debug = false;
assert debug = true;
if (debug) // do something.
OR
assert validate();
// later
private boolean validate() {
return passed;
}
Peter Lawrey
- 525,659
- 79
- 751
- 1,130
-
@Peter Lawrey when we are going to develop code then to test we are going to use assertions but if there are runtime assigned values in that test expression ...then those assertions should be enabled even when deployed know? – satheesh Mar 23 '11 at 09:20
-
The code for the tests will be there. When you run the program, the JVM will optimise the code to either include your assertions if they are on and exclude them if they are off. – Peter Lawrey Mar 23 '11 at 09:27
-
@Peter Lawrey thanks...this is not my doubt....let me tell in this way..we are using assertions for checking and why to disable assertions they are needed all the time rite...even when it is at user...(as it handles based on user input and check...) – satheesh Mar 23 '11 at 09:33
-
1Assertions should be used for detecting programming errors. To check user input you should use other means such as `if (userInput > MAXIMUM) System.out.println("Number is too large, must be less than "+ MAXIMUM+" , try again")` You should not rely on assertions for validating user input as these are not designed to be friendly. Assertions should be used for the things that you can turn off once you know the program is working. – Peter Lawrey Mar 23 '11 at 09:53
-
@Peter Lawrey...last and final doubt...can u give a small example where assertions are needed during development and they are not needed when it deployed.....(As i am thinking assertions conditions that are needed in development also should test at deployment...) i am expecting an example that will clear my doubt in this way please... – satheesh Mar 23 '11 at 10:04
-
@a supportive statement to my above one....whether we always should substitute some if statements or conditional statements instead of assertion statement while deploying? if not needed can u get me the case where it not needed please – satheesh Mar 23 '11 at 10:07
-
@satheesh I think that this question http://stackoverflow.com/questions/368750/some-anti-patterns-on-using-assert-java-and-others. Can help you understand when to use asserts and when if checks and will hopefully allow you to not get into a situation where you need your asserts in deployment in the future. – Simeon Mar 23 '11 at 10:19
-
@satheesh, You would use an assert to say for example that an argument must not be null. e.g. `assert arg != null` If coded correctly, your arg will never ben `null` However you may have a bug in your code or you may introduce a bug in the future and the assert will allow you pick up the bug quickly. Once the bug is fixed, you don't need the assert, but you leave it there in case you change the code later. – Peter Lawrey Mar 23 '11 at 10:22
-
An assert can also serve as documentation of the assumptions your code makes. e.g. `assert arg >= 0;` means anyone calling this code knows they shouldn't pass a negative argument and the code will check for that in development (which is why it is better than just a comment which states the same thing) – Peter Lawrey Mar 23 '11 at 10:24
2
It generally means that since assertions are purely a development tool while you develop you can run your VM with the -enableassertions or -ea switches which will execute your asserts during runtime, this is the "assertions let you test your assumptions during development" part of the statement.
I'll assume that in the context of what you're reading "deployment" (production maybe ?) means that the VM is run without -enableassertions or -ea which will not run your assertions (it will just skip them) thus "leaving behind no overhead or debugging code to track down and remove".
Simeon
- 7,582
- 15
- 64
- 101
-
ok sir i understood...but when the program is given to the end user after development where we are not enabling assertions then how those assumptions errors or validations will be handled when the values of the expression are going to get at runtime.. – satheesh Mar 23 '11 at 09:14
-
It depends on what you're doing. If you're giving the user your application(just a jar maybe) and letting him run it in his VM you don't need to worry since assertions are off by default. If you're making a web application it depends on the server you're using, but I can almost guarantee you that any server will run your application with assertions off by default in production mode. When assertions are off they will just be skipped/ignored during runtime. This could help clear things up firther http://download.oracle.com/javase/1.4.2/docs/guide/lang/assert.html. – Simeon Mar 23 '11 at 09:27
-
thanks...this is not my doubt....let me tell in this way..we are using assertions for checking and why to disable assertions they are needed all the time rite...even when it is at user...(as it handles based on user input and check...) – satheesh Mar 23 '11 at 09:32
-
aah I understand now :) well I'm sure you figured this out already, but you shouldn't be using assertions for checks you need in production. Can you tell me if you're making a web application or are you going to let the user run your app in his own VM ? – Simeon Mar 23 '11 at 09:55
-
I don't know if there is a way to control VM arguments from a jar manifest (but I kind of doubt it). So your best bet might be to parse your source and change your `assert` statements to `if` statements. If you're using a web server you need to find a way to make it run assertions in production. – Simeon Mar 23 '11 at 09:58
