5 replies to this topic

[Roman Y]

Well as you might have guessed I have trouble with the assertion in Java. here I've written a method that uses recursion to calculate the sum of numbers from 0 to n

public double sumUpTo(double n)

	{

		assert n >= 0;

		double sum;

		if(n==0)

			return 0;

		sum = n + sumUpTo(n-1);

		return sum;

	}

But for some reason assert is not doing much. I get the same error when I have it.

It goes: Exception in thread "main" java.lang.StackOverflowError
and the only difference is that with the assert it first points at the line where it's written and after it points at the line of the calculation repeatedly. So was I missinformed when I was told that when using assort only the error messege of not passing assort line should pop up and the program should abort, in wich case I shouldn't get the exceptions at the calculation line.

thanks in advance.

[Roman Y]

ok I've just read that: Do not use assertions for argument checking in public methods.

So I've made the method a privat one that is used by another method to calculate something else, and it's not controlling the argumet anymore it's controlling the private class variable that is depending on n being positive etc but I keep geting the same results... so what am I doing wrong?

[wim DC]

Your code works just fine. Stackoverflow happens when you're nested to deeply so you're probably using a big number on that function.
How deep you can go depends on the stack size which can be changed ->thilina's blog: How to increase the java stack size

(This has nothing to do with your assertion more with recursion ;) )

You're probably better of with a simple for-loop for this

Edited by wim DC, 16 August 2010 - 03:14 AM.

[Roman Y]

ok... well the number I tryed with was -3 shouldn't the assersion abort the program right there and prevent the stackOverflow? Or did I missunderstand how the assersion works alltogether?

[wim DC]

Maybe assertions aren't active. Test the following:

public static void main(String[] args){

  assert false : "assertions are turned on.";

  System.out.println("Assertions are not active.");

}

Quote

Enabling and Disabling Assertions

By default, assertions are disabled at runtime. Two command-line switches allow you to selectively enable or disable assertions.

To enable assertions at various granularities, use the -enableassertions, or -ea, switch. To disable assertions at various granularities, use the -disableassertions, or -da, switch. You specify the granularity with the arguments that you provide to the switch:

no arguments
Enables or disables assertions in all classes except system classes.
packageName...
Enables or disables assertions in the named package and any subpackages.
...
Enables or disables assertions in the unnamed package in the current working directory.
className
Enables or disables assertions in the named class
For example, the following command runs a program, BatTutor, with assertions enabled in only package com.wombat.fruitbat and its subpackages:

java -ea:com.wombat.fruitbat... BatTutor
If a single command line contains multiple instances of these switches, they are processed in order before loading any classes. For example, the following command runs the BatTutor program with assertions enabled in package com.wombat.fruitbat but disabled in class com.wombat.fruitbat.Brickbat:

java -ea:com.wombat.fruitbat... -da:com.wombat.fruitbat.Brickbat BatTutor
The above switches apply to all class loaders. With one exception, they also apply to system classes (which do not have an explicit class loader). The exception concerns the switches with no arguments, which (as indicated above) do not apply to system classes. This behavior makes it easy to enable asserts in all classes except for system classes, which is commonly desirable.

To enable assertions in all system classes, use a different switch: -enablesystemassertions, or -esa. Similarly, to disable assertions in system classes, use -disablesystemassertions, or -dsa.

For example, the following command runs the BatTutor program with assertions enabled in system classes, as well as in the com.wombat.fruitbat package and its subpackages:

java -esa -ea:com.wombat.fruitbat...
The assertion status of a class (enabled or disabled) is set at the time it is initialized, and does not change. There is, however, one corner case that demands special treatment. It is possible, though generally not desirable, to execute methods or constructors prior to initialization. This can happen when a class hierarchy contains a circularity in its static initialization.

If an assert statement executes before its class is initialized, the execution must behave as if assertions were enabled in the class. This topic is discussed in detail in the assertions specification.

taken from: Programming With Assertions

[Roman Y]

oh. ok, I did not know that it could be disabled, runing program from Eclipse so I guess I should go into the options there and look around. Thanks for the help.