java assertions

R

richnjones

Hello,

I was thinking about assertions in java and I dont really understand
why they are needed. I have read the article on the sun web site.

http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html

and perhaps Im being tired but I dont see why you cannot just throw
runtime exceptions

why is

assert true;

better than

if (true)
throw new RuntimeException(...)

am I missing something? I know C++ makes use of assertions. Is this
because they dont have built-in exceptions?


Thanks for any help

Richard
 
T

Tom Hawtin

I was thinking about assertions in java and I dont really understand
why they are needed. I have read the article on the sun web site.
assert true;

better than

if (true)
throw new RuntimeException(...)

It's shorter (and doesn't skip on curlies). It can also be switched off
(or not switched on) for improved performance, which may or may not be a
good feature.
am I missing something? I know C++ makes use of assertions. Is this
because they dont have built-in exceptions?

C++ does have built-in exceptions. There are three misconceptions that
may be at play here:

o C++ does not include a library? Not true. The standard library is
part of the C++ standard (including the part formerly known as "STL").

o The C++ core language does not reference the standard library? Not
true. What happens if new fails? dynamic_cast<> of a reference (not
pointer) type fails?

o The C++ core language has asserts? Not true. assert is a macro (it
should be upper case by rights) of the standard library (and also the C
standard library).

Tom Hawtin
 
L

Lew

Tom said:
It's shorter (and doesn't skip on curlies). It can also be switched off
(or not switched on) for improved performance, which may or may not be a
good feature.

Assertions are not Exceptions. They work differently, and they have different
purposes.

Assertions are for things that should literally never happen in a program,
"program invariants". For example, you might

for( int i = 0; i < 100; ++i )
{
assert i >= 0 && i < 100;
...
}

Seems trivial, but how about

private continueWorkOn( MyType something )
{
assert something != null;
...
}

This assertion would not work in a public method. How can you assert that
someone else will not pass you a null value? But in a private method, it makes
sense - if you get a null value in your own code then there is a programming
error.

That's the point in a nutshell - asserts catch programming errors, exceptions
catch runtime (data) errors.

That's why asserts get turned off in production. You have fixed all your
programming errors before production, haven't you?

Not sure that you have? If you had used asserts (wisely), you would be.

- Lew
 
P

Patricia Shanahan

Lew said:
Assertions are not Exceptions. They work differently, and they have
different purposes.

Assertions are for things that should literally never happen in a
program, "program invariants". For example, you might

for( int i = 0; i < 100; ++i )
{
assert i >= 0 && i < 100;
...
}

Seems trivial, but how about

private continueWorkOn( MyType something )
{
assert something != null;
...
}

This assertion would not work in a public method. How can you assert
that someone else will not pass you a null value? But in a private
method, it makes sense - if you get a null value in your own code then
there is a programming error.

That's the point in a nutshell - asserts catch programming errors,
exceptions catch runtime (data) errors.

That's why asserts get turned off in production. You have fixed all your
programming errors before production, haven't you?

Not sure that you have? If you had used asserts (wisely), you would be.

- Lew

I think the main value of assertions is in helping testing shake loose
more bugs. Often, in complicated systems, an actual failure only results
from a combination of problems.

Maybe usually the null pointer is only passed to modules that can cope
with it, but in some very unusual combination of conditions it causes an
NPE.

The assertion makes sure the null pointer will be detected if even one
test case makes it happen once, without the rest of the conditions that
would lead to an NPE.

Patricia
 
C

Chris Uppal

why is

assert true;

better than

if (true)
throw new RuntimeException(...)

It isn't -- in fact it's much worse. Assertions are a form of /documentation/
and shouldn't be used for runtime checks in deployed applications. Think of
this

assert blah blah

as equivalent to this comment

// Note: we assume that blah blah

with the extra benefit that the first form can be checked mechanically during
development if you choose to turn assertion-checking on.

On the other hand, if you need a runtime check of some sort, then you should
have proper code to make the check and throw a properly documented (and
probably but not necessarily checked) exception. An assert is not a substitute
for several reasons, one of which is that asserts can be and are turned off.

-- chris
 
T

Tom Hawtin

Lew said:
Assertions are not Exceptions. They work differently, and they have
different purposes.

Assertions are for things that should literally never happen in a
program, "program invariants". For example, you might

For example, I should never dereference null or pass illegal arguments.
That's the point in a nutshell - asserts catch programming errors,
exceptions catch runtime (data) errors.

IllegalArgumentException, NullPointerException - aren't they usually
caused by programming errors? Seems more like a potential distinction
between checked and unchecked Exceptions.
That's why asserts get turned off in production. You have fixed all your
programming errors before production, haven't you?

Not sure that you have? If you had used asserts (wisely), you would be.

Wow!!!!!!1111!!

You have no bugs in your production software?


I think Chris Uppal's comment come closest to my use of exceptions. They
are executable comments.

However, in general I use asserts (where I am "absolutely certain" they
will never throw) because they are shorter. If it was too much clutter,
I wouldn't bother. Other times I'm not sure about the performance, so
err on the side of caution. How fast is Thread.holdsLock for instance
(note I particularly want to avoid wasting cycles whilst I am holding a
lock)? I don't want to waste my time checking for something that will
never happen.

Tom Hawtin
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top