Exercises in Programming Style–Tantrum

NOTE : read the rest of the series, or check out the source code.

If you enjoy read­ing these exer­cises then please buy Crista’s book to sup­port her work.

exercises-prog-styles-cover

Fol­low­ing on from the last post, we will look at the Tantrum style today.

 

Style 21 – Tantrum

Constraints

  • Every sin­gle pro­ce­dure and func­tion checks the san­i­ty of its argu­ments and refus­es to con­tin­ue when the argu­ments are unrea­son­able.
  • All code blocks check for all pos­si­ble errors, pos­si­bly print out con­text-spe­cif­ic mes­sages when errors occur, and pass the errors up the func­tion call chain.

 

Last week we looked at the Con­struc­tivist style where we pro­vide fall­back val­ues wher­ev­er pos­si­ble to allow the pro­gram to con­tin­ue in the face of an anom­aly. The Tantrum style we’ll look at today is the oppo­site.

In this style, any invalid input or error will be met with an excep­tion that ter­mi­nates the pro­gram flow, as you can see from the func­tions below.

Style21_01

Style21_02

Style21_03

Style21_04

 

This approach to Fail fast, Fail loud­ly has often been her­ald­ed as a desir­able char­ac­ter­is­tic of a fault-tol­er­ant sys­tem. For us devel­op­ers, it’s also the easy way — we don’t have to think about fall­back strate­gies which can be a chal­lenge on its own, and some­times there might not be a good fall­back strat­e­gy at all.

But as we dis­cussed in the last post, adopt­ing a well thought-out fall­back strat­e­gy can have a mas­sive impact on the user expe­ri­ence. And as Jeff Atwood wrote a long time ago (and it’s still applic­a­ble today), the most impor­tant con­sid­er­a­tion should be the needs of your users.

If we adopt a “fail as often and as obnox­ious­ly as pos­si­ble” strat­e­gy, we’ve clear­ly failed our users. But if we cor­rupt or lose our users’ data through mis­guid­ed attempts to pre­vent error mes­sages– if we fail to treat our users’ data as sacro­sanct– we’ve also failed our users. You have to do both at once:

  1. If you can safe­ly fix the prob­lem, you should. Take respon­si­bil­i­ty for your pro­gram. Don’t slouch through the easy way out by plac­ing the bur­den for deal­ing with every prob­lem square­ly on your users.
  2. If you can’t safe­ly fix the prob­lem, always err on the side of pro­tect­ing the user’s data. Pro­tect­ing the user’s data is a sacred trust. If you harm that basic con­tract of trust between the user and your pro­gram, you’re hurt­ing not only your cred­i­bil­i­ty– but the cred­i­bil­i­ty of the entire soft­ware indus­try as a whole. Once they’ve been burned by data loss or cor­rup­tion, users don’t soon for­give.

The guid­ing prin­ci­ple here, as always, should be to respect your users. Do the right thing.

 

You can find the source code for this exer­cise here.