Good Code Plans for Problems

2012-09-03

(Another post in my "What is 'Good Code'?" series...)

What should you do when software doesn’t work the way you expect?

[caption id=”attachment_360” align=”aligncenter” width=”500”] Surprising behavior. Photo credit: epicfail.com.[/caption]

You have to have a plan. The plan could bring one (or several) of the following strategies to bear:

Reject bad input as early as possible using preconditions.
Get garbage in, put garbage out.
Throw an exception and make it someone else's problem.
Return a meaningful error.
Log the problem.

These choices are not equally good, IMO, and there are times when each is more or less appropriate. Perhaps I’ll blog about that in another post…

Regardless of which strategy or strategies you pick, the overriding rule is: develop, announce, and execute a specific plan for handling problems.

This rule applies at all levels of code — low-level algorithms, modules, applications, entire software ecosystems (see my post about how software is like biology). The plan can be (perhaps should be) different in different places. But just as the actions of dozens of squads or platoons might need to be coordinated to take a hill, the individual choices you make about micro problem-handling should contribute to a cohesive whole at the macro level.

Notice that I’ve talked about “problems,” not “exceptions” or “errors.” Problems certainly include exceptions or errors, but using either of those narrower terms tends to confine your thinking. Exceptions are a nifty mechanism, but they don’t propagate across process boundaries (at least, not without some careful planning). Sometimes a glut of warnings is a serious problem, even if no individual event rises to the level of an “error.”

Action Item

Evaluate the plan(s) for problem-handling in one corner of your code. Is the plan explicit and understood by all users and maintainers? Is it implemented consistently? Is it tested? Pick one thing you can do to improve the plan.

Comments

How to turn coding standards into epic fails — or not « Codecraft, 2012-09-27:

[...] follow the codebase’s error and exception strategy. (Example: “In C++, use RAII to guarantee exception safety. Make sure all errors are [...]
Why Exceptions Aren’t Enough « Codecraft, 2012-10-09:

[...] (This post is a logical sequel to my earlier musings about having a coherent strategy to handle problems.) [...]
Don’t forget the circuit breakers « Codecraft, 2013-01-11:

[...] One design pattern that Nygard recommends was new to me, but it rang true as soon as I saw its description. Like many classic patterns, I’ve implemented variations on it without knowing the terminology. I like Nygard’s formulation, so I thought I’d summarize it here; as I’ve said before, good code plans for problems. [...]