File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Beginning Java and the fly likes How about this Assertion? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "How about this Assertion?" Watch "How about this Assertion?" New topic
Author

How about this Assertion?

Jose Campana
Ranch Hand

Joined: May 28, 2007
Posts: 339
Hello there !

Quick Question:

Is it appropriate to use an Assertion to validate a switch's default(that should never ever happen) when the switch block itself is inside a public method ? (and possibly switching one of the public method's arguments)

Thanks in advance. your replies are very important!
Sincerely,
Jose
Stevi Deter
Ranch Hand

Joined: Mar 22, 2008
Posts: 265

Jose,

That sounds like a valid use of Assertions to me.

It would help you discover during development if you've changed the assumptions of valid values passed in via the parameter (e.g., you hadn't updated the switch to include a value you discovered you needed).

Of course, all caveats about Assertions apply -- they are a tool to help discover defects in development, and production applications should disable Assertions.


There will always be people who are ahead of the curve, and people who are behind the curve. But knowledge moves the curve. --Bill James
Jose Campana
Ranch Hand

Joined: May 28, 2007
Posts: 339
Thank you Stevi !

I needed to know If that case was right ! thanks for the reply!

Good Luck,

Jose
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
The fact that it's inside a public method is not necessarily a problem. But if it's switching on one of the method arguments, then I would say it's generally better to throw an IllegalArgumentException for something that should never happen:

Note that not only does the JavaDoc explain what the legal values are, but the exception message does too, and tells you what the erroneous value was. This can be very helpful later when debugging.

In a case like this, since the method is public (and I'm assuming the class is too), there really isn't any way to be sure that no one will call this method with an incorrect value. Unless, perhaps, you control all code that will ever use this class, and will always make sure that your assertion will be correct. But that's unlikely, a lot of work, and unreliable. Better to code in a check that will always be there, even if assertions are disabled. So an assertion is not appropriate here. Plus, a bad input value is exactly what IllegalArgumentException is for - might as well use it when it's appropriate.


"I'm not back." - Bill Harding, Twister
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Jim Yingst:
Better to code in a check that will always be there, even if assertions are disabled.


Even better to code the method in a way that no check is needed, for example by using enums instead of int values.


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
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stevi Deter:

Of course, all caveats about Assertions apply -- they are a tool to help discover defects in development, and production applications should disable Assertions.


I totally disagree. Production applications should fail fast (if they fail at all). http://en.wikipedia.org/wiki/Fail-fast
Stevi Deter
Ranch Hand

Joined: Mar 22, 2008
Posts: 265

Originally posted by Ilja Preuss:

I totally disagree. Production applications should fail fast (if they fail at all). http://en.wikipedia.org/wiki/Fail-fast


I agree with the principle of fail-fast, but I don't think Assertions are the right way to do it.

Actually, I generally don't use Assertions at all. But I do aggressively check parameters and throw plenty of IllegalArgumentExceptions and similar as relevant.

My clients will tolerate a nicely formatted error message that we just can't go forward, but they won't put up with an app up and dying, a la Assertions failing.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
We don't use assertions, either - simply because they are disabled by default. We don't want that behavior.

Using assertions shouldn't hold you from showing nicely formatted error messages, though. You can catch AssertionErrors just as you would catch IllegalArgumentExceptions.
 
wood burning stoves
 
subject: How about this Assertion?