• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Java exception and assert idioms

 
Jay Bromley
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello all,
I've got a bit of a question about Java idioms. One is about exceptions and the second about using assert vs. InvalidArgumentException.
First, exceptions: I'm having some trouble deciding between the following two idioms (assume these two methods are inside the same class):

or

In the first form, the higher level code (doFoo) is simpler, but it is not readily apparent where the InvalidBarException comes from without looking at verifyBar. The second form makes things clearer, I think, but may make doFoo harder to read, especially if exceptions are being logged and stack traces printed and so on. What's more, in the second form the if (isBarValid() != true) { ... } is used in several places, this could lead to a good amount of code duplication. The first method of course avoids this, there only has to be one if statement.
The second question is about the use of assert vs. IllegalArgumentException for indicating problems with parameters passed into methods. They seem almost identical to me except that assert isn't available pre 1.4. Is there an accepted idiom for this? Or should I just do what feels good (for me it's assert.)
So, does anyone have any opinions on these? I think I've got a good grasp on the language, but I'm still trying to get familiar with Java idioms.
Thanks and regards,
jb
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jay,
I like the first way better and prefer assertions for argument checking.
It seems clear enough to me that a likely candidate for throwing the InvalidBarException would be a method called verifyBar. The second way is not horrible, I just don't think it's worth the extra effort.
If I did go with the second way I would get rid of the explicit test for true:

Hope this helps,
George
[ January 16, 2004: Message edited by: George Marinkovich ]
 
Ken Krebs
Ranch Hand
Posts: 451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jay,
Regarding question #2:
The Java Assert facility is only useful for testing/debugging because assertions can be disabled at runtime. They therefore cannot play a role in any needed runtime behavior. If you need runtime checking, throw an exception.
If you don't require the runtime check, your docs should explicitly state a contractual obligation to callers. Whether this approach is an appropriate alternative to a runtime check is dependent upon how it is used. If you have control over the callers, you may be able to use the contractual approach.
[ January 16, 2004: Message edited by: Ken Krebs ]
 
james airey
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't like throwing exceptions for fun. I think they should only be used for exceptional circumstances.
I guess that means I tend towards returning true or false, but again that would depend on what problems you think you might encounter.
maybe I would do something like:
public boolean checkBar() throws InvalidBarException
{
try {
if (predictable problem){
return false;
}
else
{
return true;
}
}
catch (Exception e)
{
throw new InvalidBarException(e);
}
}
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with all what Ken wrote above, with this little nuance though. Arguments checking, along with checking other preconditions, could be done through assertions, but in private/protected methods only, and in any case not in public ones. Assertions are perfect for debugging, but as private methods are called under your own control by definition, you may not care about assertions disabled or not at runtime. In that context, assertions may help to avoid redundants checks which is a good thing.
Best,
Phil.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic