Is this an Exception Handling abuse?

I have this method, that can return three different response.

At first, it was supposed just only return two, so I make its return type to Boolean

like:

public static boolean isLoteWaitingForImage()

And some business logic came out with that it can has another result, so the method was modified to

public static boolean isLoteWaitingForImage() throws ImageNotPendingException 

If a certain select return a null value, but one row its return开发者_开发技巧 true, if its not null i will return false. If no row was acquired from the select I will throw an ImageNotPendingException cause it doesn't apply for the given filters in the where clause.

Also thought about doing it in this Way, I have this new Class with the types that are valid to return from the method isLoteWaitingForImage(), with 3 constants properties called:

public class LoteResponse {
    public static int VALID = 1;
    public static int INVALID = 2;
    public static int NO_IMAGE_PENDING = 3;
}

So I will have this new method:

public static int isLoteWaitingForImage() {

    return LoteResponse.VALID;
}

Having this on table, I have these two questions:

• Any "other" idea about how to accomplish this needing?

• Which method is a better practice?

Yes, that looks like an abuse to me.

It would be reasonable to throw the exception if the method simply shouldn't be called when no image is pending. Can the client always know that? Does it represent a bug, or something else going badly wrong for them to be calling it in that state? If not, don't use an exception.

It looks to me like you need an enum.

public enum LoteResponseState
{
    Valid,
    Invalid,
    NoImagePending;
}

public static LoteResponseState getLoteState()
{
    ...
}

• If you expect the code that calls isLoteWaitingForImage() to be directly responsible for handling the "no image pending" condition as well as the others, then use the multiple return values, but use an enum, not ints!
• If the "no image pending" condition cannot be usefully handled by the immediate calling code and instead would usually be handled higher up the call stack, then the exception is the better option.

I definitely agree that an enum is the best choice.

As a general rule, if a certain operation is not considered a serious error that will rarely occur, you should not throw an exception. Throw exceptions only for errors that the current method cannot have any way of handling in a useful way, but not as a typical return value.

I am no expert so don't take this as a best-practice advice, but I think using exceptions in this particular case seems like an overkill. I would go for some simple return values as mentioned above.

If you really want to keep track of the situation, for whatever debugging or developing reason, you could perhaps throw RuntimeException("why a runtime exception is thrown") instead. Writing an own Exception seems too excessive if you are not doing something particular with the exception.

I hope that makes some sense. :)

Go for the exception way. It does have a more explicit interface to the caller. If the caller needs to process this ImageNotPendingException make it an Checked Exception.

Returning enum is a bizarre thing as it diminishes encapsulation by delegating business detail and processing to the caller. This way the caller needs to know way too much of the calee.

Sorry about my bad english.