aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Any scenario where throwing an AssertionError directly is acceptable? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Any scenario where throwing an AssertionError directly is acceptable?" Watch "Any scenario where throwing an AssertionError directly is acceptable?" New topic
Author

Any scenario where throwing an AssertionError directly is acceptable?

Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
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


All code in my posts, unless a source is explicitly mentioned, is my own.
Ryan Beckett
Ranch Hand

Joined: Feb 22, 2009
Posts: 192
When you reach code that should never execute



Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
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

Joined: Mar 26, 2009
Posts: 8
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.


SCJP 1.6, SCWCD 1.5, MCTS, MCT
Ryan Beckett
Ranch Hand

Joined: Feb 22, 2009
Posts: 192
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

Joined: Dec 16, 2008
Posts: 1032
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

Joined: Feb 22, 2009
Posts: 192
I see. Thanks man.
Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
Don't thank me yet. I'm still waiting to hear if someone can prove me wrong.
Paolo Dina
Ranch Hand

Joined: Aug 15, 2008
Posts: 63
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


SCJP 5
Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
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

Joined: Apr 15, 2012
Posts: 56


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).
 
 
subject: Any scenario where throwing an AssertionError directly is acceptable?