Is it legal for an assertion to create a new Class?

[Glen Iris]

Hi,

Assuming all other things are correct, will this cause the compilation for the code to fail?

int x = 1;
int y = 5;
assert(x>y):new Car();

If not, why not?

Thanks :-)

[John Stark]

The expression after the ':' is used to print a string to the screen and must evaluate to some value. So doing

assert false : doSomething();

with

void doSomething(){}

does not compile.

assert false : new Car();

compiles fine. Running it with asertions enabled will give something like 'java.lang.AssertionError: A@fjdhs' depending on the Car toString() method.

John

[Matthew Brown]

And just to be picky (you'll find that's quite common round here, but then, programming is all about attention to detail ), you aren't creating a new class there. You're creating a new instance of a class.

[Tim Moores]

I'm perennially bemused by this kind of question that can be answered with the help of a compiler a LOT quicker than posting here and waiting for an answer.

[Bert Bates]

In the case of assertions it's important to ask two questions:

- Is it legal? - which of course can be answered by the complier
- Is it appropriate, according to Sub / Oracle standards?

The "appropriate" question might be on the real exam.

[Glen Iris]

Tim Moores wrote:I'm perennially bemused by this kind of question that can be answered with the help of a compiler a LOT quicker than posting here and waiting for an answer.

Good lad Tim. Sorry to hear about your bemusement. Its just that the compiler cannot tell me if there is an error in the book or not. In order to cure you bemusement, I suggest you do a Google image search for lolcats.

[Glen Iris]

Hi John, thanks for your reply. I suppose I should have posted the question in full instead of making my own variation...

public class Clumsy{
	public static void main(String[]args){
		int j = 7;
		assert(++j>7);
		assert(++j>8):"hi";
		assert(j>10):j=12;
		assert(j==12):doStuff();
		assert(j==12):new Clumsy();
	}
}

The book states that compilation fails due to "assert(j==12):doStuff();" as it does not return a value. The book does not indicate that they're is anything wrong with the line after which is "assert(j==12):new Clumsy();".

As far as I can tell, "assert(j==12):new Clumsy();" will not return a value either. Why does the compiler not complain about this line?

Thanks.

[Glen Iris]

Matthew Brown wrote:And just to be picky (you'll find that's quite common round here, but then, programming is all about attention to detail ), you aren't creating a new class there. You're creating a new instance of a class.

thanks Matthew, I was wondering how to phrase the question when I initially typed it ;-)

[John Stark]

As far as I can tell, "assert(j==12):new Clumsy();" will not return a value either. Why does the compiler not complain about this line?

Hm, yes. The compiler wants something that gives a string which can be printed out together with the assertion error. So I guess the toString() method of the created Clumsy object is called somehow. Like in System.out.println() where you can do

System.out.println(new Clumsy());

but you cannot do

System.out.println(doSomething());

with

static void doSomething(){}

John

[Matthew Brown]

Glen Iris wrote:As far as I can tell, "assert(j==12):new Clumsy();" will not return a value either. Why does the compiler not complain about this line?

It does have a value - the new Clumsy object. It's not a String, but that's not important - it will accept any value there. John's example demonstrates the difference quite nicely.

[Glen Iris]

That makes sense, thanks Johan and Matthew