Summary
A method that can fail for one reason or several and answers with a boolean loses the most useful information there is: why. The caller receives false and does not know what to do next, retry, tell the user, map to an HTTP status, compensate. Writing the cause to a log does not help, because logs are not an API: they can be absent, filtered, uncorrelated or out of reach.
The habit has a history. C had no boolean type before C99; functions returned an int, zero for false, anything else for true, and a whole culture of return codes grew around it, zero for success and negative for error, or minus one plus errno. The type arrived, the culture stayed, and it followed us into languages that had every means to do better.
The alternatives are not exotic. In C, named error codes the caller can switch on, or a bitmask when several conditions can hold at once, as in a form validation. Elsewhere, a Result type carrying success or failure with an error code and a message, typed business and technical exceptions in the spirit of domain-driven design, or simply an enum. The style matters less than the rule: expose a cause the caller can act on.
My rules are short. Avoid the boolean return, ban it where you can; return an error code, a Result, an error type, an enum or a bitmask; let logs help diagnosis without ever standing in for the contract. Choose the style that suits you, but do not choose the anti-pattern.
Key ideas
- A boolean return hides the why: the caller cannot choose between retry, user message, HTTP mapping or compensation.
- Logs are not an API; they can be absent, filtered, uncorrelated or inaccessible, and parsing them is fragile and non-contractual.
- The habit dates from C before C99, when there was no boolean type; the type arrived, the return-code culture stayed.
- Named error codes or a bitmask in C, a Result type, typed exceptions or an enum elsewhere: any style beats the anti-pattern.
- Tests can only assert a precise cause if the contract carries one.
Why I wrote this
To name an ordinary anti-pattern, the method that answers false without saying why, trace it back to C before C99, and give the caller the alternatives, a named error code, a Result, a typed exception or an enum, that return a cause it can act on.