This week's book giveaway is in the Clojure forum.
We're giving away four copies of Clojure in Action and have Amit Rathore and Francis Avila on-line!
See this thread for details.
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Any scenario where throwing an AssertionError directly is acceptable?

 
Ruben Soto
Ranch Hand
Posts: 1032
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Versus using the assertions mechanism.

I thought there was no such scenario, but one of the mocks I am doing claims otherwise with no explanation about it.

Thanks,

Ruben
 
Ryan Beckett
Ranch Hand
Posts: 192
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When you reach code that should never execute



 
Ruben Soto
Ranch Hand
Posts: 1032
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the example, Ryan. But, is that really acceptable? The purpose of assertions I think was to test things that should never happen in your code, so that you can test during debugging. But when you are in the production stage you simply compile with assertions disabled and eliminate any overhead. If you throw an AssertionError explicitly, then that will remain in the code forever. So I don't think it's really acceptable. Do you disagree?

I think your example would work better with an assert statement instead of the throw statement.
 
Rex Tan
Greenhorn
Posts: 8
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ryan Beckett wrote:When you reach code that should never execute





you should never throw AssertionError's since it's a subtype of error. Using the assert keyword is much better since you can enable assertions with java -ea when you need to test your code. Errors should generally not be caught/handled.
 
Ryan Beckett
Ranch Hand
Posts: 192
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think was to test things that should never happen in your code



I kinda bypassed that concept. Of course your supposed to use assertions to test pre-conditions during the testing phase of the software process. e.g.




Yes, assertions aren't needed during the deployment phase. You must also remember to never use assertions inside public methods because the programmer using your code won't take care of any exceptions that are thrown.

You asked when your would DIRECTLY throw an AssertionError. And, my example is perfect. It you disagree, read page 393 of K & B SCJP 6 Study Guide.

And, Tex, I really don't think it matters whether I throw an AssertionError or use assert(false); in this situation, either way the code block should never be reached and an AssertionError will be thrown, regardless. And, your right, Errors should never be caught. I DIDN'T catch the error.
 
Ruben Soto
Ranch Hand
Posts: 1032
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ryan,

I looked at the page that you pointed out, and in that case they don't throw an AssertionError, but use an assert statement. The problem with throwing an AssertionError directly is that the throw statement will stay in your compiled code always, whereas you can bypass assertion code from being generated by disabling assertions during compilation when the project is ready to be delivered (and outside from the testing/debugging phase.) So yes, I still think there is no legitimate scenario where you should throw an AssertionError directly. Unless you (or anyone else) proves me wrong.
 
Ryan Beckett
Ranch Hand
Posts: 192
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I see. Thanks man.
 
Ruben Soto
Ranch Hand
Posts: 1032
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Don't thank me yet. I'm still waiting to hear if someone can prove me wrong.
 
Paolo Dina
Ranch Hand
Posts: 63
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, when you need/want assertions but can't use assert statemets directly. For example...


...
An acceptable alternative is:

default:
throw new AssertionError(suit);

...
Moreover, the alternative is legal under some circumstances where the assert statement is not. If the enclosing method returns a value, each case in the switch statement contains a return statement, and no return statement follows the switch statement, then it would cause a syntax error to add a default case with an assertion. (The method would return without a value if no case matched and assertions were disabled.)


Context of the quote: Internal Invariants.

HTH
 
Ruben Soto
Ranch Hand
Posts: 1032
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paolo Dina wrote:Yes, when you need/want assertions but can't use assert statemets directly. For example...


...
An acceptable alternative is:

default:
throw new AssertionError(suit);

...
Moreover, the alternative is legal under some circumstances where the assert statement is not. If the enclosing method returns a value, each case in the switch statement contains a return statement, and no return statement follows the switch statement, then it would cause a syntax error to add a default case with an assertion. (The method would return without a value if no case matched and assertions were disabled.)


Context of the quote: Internal Invariants.

HTH

Thanks a lot, Paolo. That's exactly what I was looking for.
I still think you could make assertions work in that case however, because you could add a dummy return statement after the assert statement in the default block. However this would add the same overhead as the throw statement when assertions were disabled I suppose. So it probably makes sense in that case to throw an AssertionError directly.
 
Will Zelan
Ranch Hand
Posts: 56
Flex Python Windows Vista
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Rex Tan wrote:
you should never throw AssertionError's since it's a subtype of error.


That's not quite true. It's fine to throw Errors to "indicate serious problems that a reasonable application should not try to catch" (to quote the Error javadoc).

Ryan Beckett wrote:When you reach code that should never execute


I agree, there's a few very limited scenarios where this makes sense.

When switching on an enum, it may be better to avoid using default. That way compilers (Eclipse at least) can warn if someone later extends the enum without updating the switch. Very handy.



You can't use 'assert' this way, as you'll get a compile error that the method doesn't provide a return. Throwing an Error is valid here I believe. It's saying: the code to process this request does not exist - I cannot proceed. AssertionError a good match, you're making a assertion to catch programming bugs.

An example like this is given in Effective Java (great book).
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic