1

I would like to ask a follow-up to a question I just asked: Better to have 2 methods with clear meaning, or just 1 dual use method? I now understand why it is best to separate charge(float c); and getBalance();.

But, every method has the opportunity to return a value. So, maybe use that opportunity and just return a boolean that means that there was no trouble with executing the method?

public class Client {
    private float bal;
    float getBalance() { return bal; }

    boolean charge(float c) {
        if(bal < 0) return false; // some weird, illegal, state
        bal -=c;
        return true;
    }
}

Returning booleans for success / failure enables an (optional) extra layer for exception handling.

I mean, if you are not interested in the returned boolean then just ignore it. I don't know, I just think why not just return "something"?

Community
  • 1
david.t
  • 437
  • 4
  • 7
  • are you trying to put each and every exception you get in a true false? That's bad. On the one hand you will cover an IllegalArgumentException but what if it is an InterruptedException, then you're in for a whole lot of trouble. – Pieter B Feb 05 '16 at 20:34
  • sorry. I mean do what I can to handle the exception in the catch(), then return "false". – david.t Feb 05 '16 at 20:40
  • 5
    [Return magic value, throw exception or return false on failure?](http://programmers.stackexchange.com/questions/159096/return-magic-value-throw-exception-or-return-false-on-failure) – gnat Feb 05 '16 at 20:43

1 Answers1

2

You appear to be arguing that an "unused" return value is a wasted opportunity to provide the caller with more information. I would instead argue:

  1. Providing a return value adds one more thing that users of your API have to learn about and keep track of.

  2. Providing a return value that the caller needs to check (as is typically the case with a success/failure boolean) introduces the possibility of the caller forgetting to check that return value.

So returning something rather than nothing is not automatically a win-win. Whether it's the right thing to do depends on other considerations.

  • Is it possible to implement this method in a way that makes it impossible to fail? (ignoring cosmic radiation and mice chewing on the wiring and so on) Then return nothing. Users like it when things can't possibly fail.

  • Is the failure unusual? Then consider throwing an exception instead. The debate between exceptions and return values is far too complicated to get into here (see gnat's proposed duplicate), so I'll just point out that return values will silently fail to do anything if the caller isn't checking for them, while exceptions are "impossible to ignore".

  • Is the failure likely to indicate a bug in the calling code? Then consider assertions or exceptions that provide some helpful error message to the programmer that made the mistake.

In this case you could potentially answer yes to all three questions. You can prevent bal from becoming negative in your other methods. You can probably assume that most of your clients will have a positive balance most of the time. You can argue that the caller should always check getBalance() before charge(). This is where you to have to make a subjective judgment call.

P.S.:

Returning booleans for success / failure enables an (optional) extra layer for exception handling.

If the possibility of failure is unavoidable, then I would agree that you should do something when a failure happens other than silently ignoring it. But there are many ways to notify the caller of the issue or at least enable the caller to detect the issue, such as throwing your own exceptions, asserting on the failure, exposing the status of the account via another method, or returning an enum of various error codes. Returning a boolean is just one of many options. Sometimes it's the best option, but not always.

Community
  • 1
Ixrec
  • 27,621
  • 15
  • 80
  • 87
  • I'm not just thinking about success / failure. My thinking is about methods that logically have no return value. And, were I to return a value, 99.99% of the time it'd be ignored. no harm, no foul. But, why not throw some potentially useful value back to the invoker. If he wants to look at it, fine. If he wants to ignore it, also fine. – david.t Feb 07 '16 at 22:08