Java exception and assert idioms

[Jay Bromley]

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):

void doFoo() throws InvalidBarException {
    // Check if the bar is valid
    verifyBar();
    ...
}
void verifyBar() throws InvalidBarException {
    if (bar is not valid) {
        throw new InvalidBarException();
    }
}

or

void doFoo() throws InvalidBarException {
    // Check if the bar is valid
    if (isBarValid() != true) {
        throw new InvalidBarException();
    }
}
void isBarValid() throws InvalidBarException {
    boolean valid = false;
    if (bar is valid) {
        valid = true;
    }
    return valid;
}

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]

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:

    void doFoo() throws InvalidBarException {
        // Check if the bar is valid
        if (isBarValid()) {        
            throw new InvalidBarException();    
        }
    }

Hope this helps,
George
[ January 16, 2004: Message edited by: George Marinkovich ]

[Ken Krebs]

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]

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]

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.