Is there a Java convention for returning true, false, or unknown?

I am writing a method which will return if something is true or not. But if the resources needed to test the condition are not available, it will not be able to return true or false.

Earlier, I was just making it a method which returns a boolean. But now, to accommodate exceptions, I am thinking of passing true or false in function arguments and using the return value as success or failure indicator for the test.

Is this the "correct and common"开发者_Go百科 way of doing it in Java? Or is something else prevalent in Java to achieve this?

Your method should return a boolean and throw an Exception if resources are unavailable.

I'd definitely make the method throw an exception if it is not able to calculate the correct answer.

Now you have to decide if the exception thrown will be checked or unchecked. It really depends on the context. Usually, I think like this: if the caller has a way to ensure that the method cannot fail, I'd make it throw an unchecked exception; otherwise, if the caller has no way to be absolutely sure that the method will not fail, then I'd make it a checked exception.

This would be the case where the caller can determine the possibility of failure:

class C1 {
  public boolean canCalculateResultNow() { ... }
  public boolean calculateResult() {
    if (cannot get resource) throw new IllegalStateException("Cannot get resource");
    ...
  }
}

Now, here's what I'd do if the caller cannot be sure that the method will be able to complete normally:

class CannotCalculateResultException extends Exception { ... }
class C2 {
  public boolean calculateResult() throws CannotCalculateResultException {
    if (cannot calculate result) throw new CannotCalculateResultException();
    ...
  }
}

Another possibility, which I really dislike and strongly discourage, is to make the method return Boolean, which is a nullable version of boolean. A Boolean can be true, false or null. You could then make the method return null if the resource is not available.

The main problem I see on this approach is that the meaning of null may not be clear. Calling code will always have to check if the result is null, and a developer (maybe even yourself some months after having written this code) will have to read the method's documentation to know what does a null result mean. An specific checked exception makes absolutely clear that something might go wrong and what can go wrong. Also, it would force the developer to prepare for the case in which something went wrong. On the approach with unchecked exceptions, the presence of the method canCalculateResult() will also indicated to the developer using the class that something might go wrong, without the need to read the documentation, and it is reasonable to assume that it is something "dangerous" to call calculareResult() without first calling canCalculateResult().

I would propose other approach: return not boolean, but Boolean and return true/false when there're resources and return null when there're no resources

It would be correct, but not a good practice. Instead, your method should return a boolean and handle exceptions if not capable of calculating the answer