my dog learned polymorphism*
The moose likes Java in General and the fly likes Assertions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Assertions" Watch "Assertions" New topic
Author

Assertions

Chris Waguespack
Ranch Hand

Joined: Jul 26, 2007
Posts: 36

I understand how and where assertions work (like for else statements that shouldn't be reached), but I am confused about how the application should respond to them. When an assertion is false, it throws an AssertionError which stops execution of the method, like an exception does, and, in some cases (like while transitioning gui screens), leaves your application with no way to close. I've found a way around this by wrapping the assert in a try/catch block but I'm not sure this was assert's intended use. Any thoughts?



Thanks,
Chris
Nicholas Jordan
Ranch Hand

Joined: Sep 17, 2006
Posts: 1282
This is an often difficult area to understand: How your application responds to ( errors and exceptions ) is how you code the response to ( errors and exceptions )

Trying to guess that before the rest of the code is written wastes time, just put System.out.println(exception.getMessage()); until, if, and when you have something that may need to be done with the message.

If it is a value that will be used later, set it to some sane default value that will not cause null pointer exceptions. If that cannot be done, then halt further exectuion of that area of the program right then and there.

Do not let troublesome conditions go into other areas of the program.


"The differential equations that describe dynamic interactions of power generators are similar to that of the gravitational interplay among celestial bodies, which is chaotic in nature."
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4636
    
    5

You really should not be calling System.exit(); ever.
You should have a highest level program trap all possible errors, handle them, and return out of the top.

Assertions are an attempt to isolate assumptions. For example, you get a DB connection from the pool, you then assert it is not null.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36478
    
  16
Disagree.

Assertions (as opposed to ordinary Exceptions) are there for testing; they should be used only in testing and then disabled in a production application.
When an AssertionError occurs you need to go and find out what happened, and most of the time, correct the code.

There may be need for ordinary Exceptions in the code as well, but thsi is a different question.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[Nick]: System.out.println(exception.getMessage());

Unfortunately this is often not enough information. Sometimes the message is null - most notably, for a NullPointerException. In such cases, the class name of the exception is very informative. And that is often not part of the message itself. So

would be more informative, because for most Throwables, toString() simply takes the class name and concatenates the message. (Note that calling toString() directly is unnecessary here, as println() will implicitly invoke it for you. But it can't hurt either.) However even toString() is often not good enough, as the stack trace also has important info. There may also be nested exceptions that you need to know about. Fortunately,

prints all this information for you. In general that's a much more useful way to get info from exceptions.


"I'm not back." - Bill Harding, Twister
Nicholas Jordan
Ranch Hand

Joined: Sep 17, 2006
Posts: 1282
Okay, Chris - with what these other three say you pretty well have the Whole Show in roadable condition.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36478
    
  16
When I said "disagree" I didn't know Pat Farrell was posting. It was not him I was disagreeing with.
Chris Waguespack
Ranch Hand

Joined: Jul 26, 2007
Posts: 36

Thanks everyone. So basically assertions should only be used while developing/debugging your application...yeah I guess that makes sense since assertions are disabled by default.

- Chris
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Campbell Ritchie:

Assertions (as opposed to ordinary Exceptions) are there for testing; they should be used only in testing and then disabled in a production application.
When an AssertionError occurs you need to go and find out what happened, and most of the time, correct the code.


And disabling assertions in production actually makes it harder to find errors in the production environment.

So, why should I disable assertions in production again?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36478
    
  16
You can always re-enable the assertions.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[Pat]: You really should not be calling System.exit(); ever.
You should have a highest level program trap all possible errors, handle them, and return out of the top.


[Campbell]: When I said "disagree" I didn't know Pat Farrell was posting. It was not him I was disagreeing with.

Well in that case, I'm going to disagree with Pat, at least a little. Assertions are often testing such fundamental assumptions that if they're wrong, you're often best off making it really obvious to the user that the program is broken. Fail immediately and loudly. If there are multiple threads going on, as Chris said, then it's quite possible that the AssertionError will terminate one thread (perhaps the GUI event response thread, for example) while leaving other threads running. This in turn may confuse the user and lead to additional errors, and may obscure the true cause of the problems. So I would argue that in such a case, System.exit(1) may be a valid way to handle the error. This is particularly true for rapid application development, where you don't care if the program fails in an ugly manner, as long as it's quick and easy to diagnose the problem. Other contexts may well require more robust handling, where System.exit() is not appropriate at all.

[Ilja]: So, why should I disable assertions in production again?

It's possible to have some checks which are (a) performance bottlenecks, and (b) unnecessary in theory, but you might want to test them anyway. In this situation you might want to include these extra checks during testing, but not in production. I've never actually encountered this situation in the wild, myself, so I expect it's pretty rare in general. I would agree at least that the vast majority of the time, we'd want to run the same code in production as in test, including code that's just for diagnosing errors that "shouldn't" happen anyway. Which in turn would suggest that (a) most such tests probably shouldn't be in assertions which can be disabled, but in code that runs always, and (b) assertions should probably be enabled by default, not disabled, for those rare cases where they might be useful. But it's unlikely Sun will change this default behavior at this point, so probably it's in our own best interest to enable assertions ourselves in most cases where they're used at all.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Campbell Ritchie:
You can always re-enable the assertions.


Yes, I know I can. I still don't know why I should disable them in the first place.

For the record, I'm very much with Jim here.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36478
    
  16
Anything which needs to be used in real life ought not to follow "assert" in the first place; it ought to look like "throw new XYZException();".
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36478
    
  16
I don't think Jim, Ilja and I are really in disagreement on this point; I think I have put my case badly.

I mean "assertions" to mean something with the "assert" keyword in which is intended to be enabled for testing only. I mean that anything which might happen in real life needs robust handling with Exceptions or similar.
And I did say that an AssertionError means correcting the code, to make sure it won't happen again.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
In which way are exceptions more robust than an AssertionError?
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36478
    
  16
Exceptions are there all the time; AssertionErrors have to be explicitly enabled.

I'm tying myself in knots here, aren't I?
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4636
    
    5

Originally posted by Jim Yingst:
[Pat]: You really should not be calling System.exit(); ever.
You should have a highest level program trap all possible errors, handle them, and return out of the top.


Well in that case, I'm going to disagree with Pat, at least a little. Assertions are often testing such fundamental assumptions that if they're wrong, you're often best off making it really obvious to the user that the program is broken. Fail immediately and loudly. If there are multiple threads going on, as Chris said, then it's quite possible that the AssertionError will terminate one thread (perhaps the GUI event response thread, for example) while leaving other threads running. This in turn may confuse the user and lead to additional errors, and may obscure the true cause of the problems. So I would argue that in such a case, System.exit(1) may be a valid way to handle the error.



Well, I think we are really agreeing, its a doctor doctor. You should not be killing only one thread. You want to fail immediately and loudly.

I'll agree that System.exit() "may" be a valid option in some cases.

But I think that the general use of System.exit() is a really bad thing, it really doesn't work all the time.

If you run Findbugs, it will whine a lot about each System.exit()
FindBugs

BTW, I strongly recommend findbugs
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Yes, we agree for the most part (which is true also for most other posters here). I only disagreed with the "ever" part of your statement, but that's a minor point really.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Campbell Ritchie:
Exceptions are there all the time; AssertionErrors have to be explicitly enabled.

I'm tying myself in knots here, aren't I?


I see. I guess I actually agree.

We never use asserts at work, exactly because they are disabled by default. Instead we use a homegrown Ensure class with static methods, which's exceptions cannot be disabled.
[ May 18, 2008: Message edited by: Ilja Preuss ]
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36478
    
  16
I hope it's the first bit you agree with, Ilja, not the second.

But I did express myself badly on that thread. Sorry.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Well, this is no fun. We're all too agreeable here. We need a good controversy to argue about.
Chris Waguespack
Ranch Hand

Joined: Jul 26, 2007
Posts: 36

Thanks for all the help! Though this brings me to another question; if you have a GUI application, should a quit menu option directly call System.exit(0); or is there a better way to handle this?

Thanks again,
Chris

Edit: I think I figured out a correct approach. System.exit(); can be called if the application is exiting safely, as requested by the user. throw new RuntimeException(); should be used if an error occurs and the application needs to exit. Sound about right?
[ May 19, 2008: Message edited by: Chris Waguespack ]
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36478
    
  16
Better to start a new thread for the new question, preferably on the Swing forum, please.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Assertions
 
Similar Threads
Assertions and unreachable statements
Dan's comprehensive exam 6. Q 16
assertions in try-catch blocks
Assertion
NX:Create/Delete invalid data