Are errors always thrown in the same way all the time?
Of course not, programmers are a varied bunch and libraries are used for multiple different purposes. For example, if you wanted to take the square root of a negative number with Math.sqrt(x);, it would return NaN instead of a mathError.
This is not a fault of the library itself, but it can produce problems down the line, such as vague nullPointerExceptions if you try to cast NaN as a long decimal from its original double form.
Why not just use if statments and throws?
The reason why a programmer would use asserts instead of an if statment like the one below is that if statments are terrible for efficiency’s sake, especially if its for testing.
if (x < 0) throw new IllegalArgumentException(“x < 0”);
Such structures are hard to evict from production code whereas assertions can be toggled by addint the -disableAssertions at the end of a javac (compile) or java (execute) command.
How would you provide an error checking solution that is both comprehensive AND efficient?
Assertions are a toglable way to throw errors when testing code. Unlike if statments, they can be disabled on compilation or runtime. The syntax for asserting a double variable x is as follows:
assert x>=0;
To further aid in bug squashing, the programmer can pass a message, or a stringified version of an object through an assert statment as follows.
assert x>=0 : x
How do you enable assertions?
By default, assertions are enabled. To enable them manually, run your java program (in this case MyApp) with the -enableAssertions flag.
Conversly, use the -disableAssertions flag to disable assertions on runtime.
But what if I want to enable/disable assertions on a class by class basis?
To do so, use this syntax
java –ea:MyClass –ea:com.horstmann.corejava –da:AnotherClass MyApp
When exactly would you use assertions?