• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Assertions

 
Ranch Hand
Posts: 36
Mac Eclipse IDE Flex
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Rancher
Posts: 4803
7
Mac OS X VI Editor Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[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.
 
Nicholas Jordan
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Okay, Chris - with what these other three say you pretty well have the Whole Show in roadable condition.
 
Campbell Ritchie
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When I said "disagree" I didn't know Pat Farrell was posting. It was not him I was disagreeing with.
 
Chris Waguespack
Ranch Hand
Posts: 36
Mac Eclipse IDE Flex
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?
 
Campbell Ritchie
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can always re-enable the assertions.
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In which way are exceptions more robust than an AssertionError?
 
Campbell Ritchie
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 4803
7
Mac OS X VI Editor Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, this is no fun. We're all too agreeable here. We need a good controversy to argue about.
 
Chris Waguespack
Ranch Hand
Posts: 36
Mac Eclipse IDE Flex
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Better to start a new thread for the new question, preferably on the Swing forum, please.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic