When "Just Return Something" Is the Wrong Call
Learning when honesty matters more than helpfulness
There is a moment in many projects where the system doesn’t completely fail — but it doesn’t fully succeed either.
Most of the data is available.
One part is missing.
A dependency is slow.
A subsystem didn’t respond in time.
And then someone says the sentence that sounds reasonable, practical, and helpful:
“Let’s just return what we have.”
This article is about why that instinct — while understandable — is often the wrong call.
A familiar situation
Imagine you are building a feature that aggregates information from multiple sources. Clients call your service, get a response, and make decisions based on it.
Most of the response is available.
One piece isn’t.
Now you have a choice:
Return what you know and omit the rest
Or return an error and say you can’t answer right now
Someone will argue that returning something is better than returning nothing. And early in your career, that argument is hard to resist.
After all, errors feel like failure.
Why approximations feel safe
Approximations are attractive for good reasons.
They:
Keep the system moving
Avoid breaking existing contracts
Make dashboards look healthy
Reduce short-term friction with other teams
If your goal is to keep things green and quiet, returning a “best effort” response feels like progress.
But this is where experience starts to matter.
Because while approximations feel safe, they are rarely free.
Who pays for uncertainty?
When you return partial data as a successful response, you don’t eliminate uncertainty — you *move it*.
You move it to:
The next service in the chain
The UI that behaves strangely
The engineer debugging a vague issue weeks later
The user who no longer trusts what they see
The system looks fine, but confidence is misplaced.
Errors, uncomfortable as they are, keep uncertainty where it belongs: close to its source.
A more useful question to ask
Instead of asking:
“Can we return something?”
Ask this instead:
“What decisions will be made based on this response?”
If the answer includes things like:
Committing state
Skipping retries
Caching aggressively
Advancing a workflow
Making irreversible choices
Then wrong data is worse than no data.
Because confident mistakes are harder to detect — and harder to undo — than explicit failures.
When returning partial data *is* the right move
This is not an argument for absolutism.
Partial responses can be the right choice when:
Consumers know the data is incomplete
Missing information is explicit and detectable
Safe fallback behavior exists
No irreversible decisions depend on it
In other words, when uncertainty is visible and manageable.
If callers can tell the difference between “empty” and “unknown,” they can act responsibly. If they can’t, they will assume correctness.
The maturity shift
There is a subtle but important shift that happens as developers grow.
Early on, the instinct is:
“Let’s return the best we can.”
Later, it becomes:
“Let’s be honest about what we don’t know.”
That shift has very little to do with technical skill.
It has everything to do with responsibility.
Senior engineers are not those who guess better — they are those who know when guessing is dangerous.
A rule worth remembering
If consumers cannot tell that data is incomplete, returning it as success is a lie.
Errors are not laziness.
They are not lack of effort.
They are an act of integrity.
They say: this system has limits, and it respects you enough to admit them.
If you are interested in a more system-level and API-design perspective on this topic, I explore the same idea from a different angle in a longer article on sandordargo.com, focusing on partial failures, contracts, and the semantics of “success” in system responses.
Climbing the ladder
Leveling up as a developer is not just about learning new tools or patterns.
It’s about learning:
When not to guess
When to push back on “just make it work”
When protecting downstream systems matters more than short-term smoothness
Sometimes the most professional response your system can give is an error.
And knowing when that is the case is one of the quiet skills that separates experienced developers from the rest.