Exercises in Programming Style–Passive Aggressive

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.


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


Style 22 – Passive Aggressive


  • 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, jump­ing out of the func­tion.
  • When call­ing out oth­er func­tions, pro­gram func­tions only check for errors if they are in a posi­tion to react mean­ing­ful­ly.
  • Error han­dling occurs at high­er lev­els of func­tion call chains, wher­ev­er it is meaningul to do so.


We have seen two con­trast­ing approach­es to han­dling excep­tions recent­ly:

  • Con­struc­tivist style where we always pro­vide fall­back val­ues to allow pro­gram to con­tin­ue
  • Tantrum style where we always throw excep­tions to ter­mi­nate pro­gram right away

Despite their dif­fer­ent respons­es to excep­tions, both styles share some­thing in com­mon — that they deal with excep­tions at the call­site. Today’s style dif­fers in this regard. Here, we’ll only con­sid­er the hap­py path and allow excep­tions (that we can’t deal with mean­ing­ful­ly in the func­tion) to escape and bub­ble up to a func­tion that’s high­er up in the call chain and CAN han­dle it in a mean­ing­ful way.


We’ll keep the solu­tion to the same struc­ture as the last two styles, but notice that we’re not explic­it­ly han­dling file excep­tions in extract­Words and removeStop­Words.




How­ev­er, any escaped excep­tions will be han­dled and logged by the top-lev­el func­tion.



If you come from a .Net or Java back­ground, this is prob­a­bly the style that you’ll most often encounter in the wild. If you’re an Erlang devel­op­er, this style per­fect­ly embod­ies Erlang’s famous Let it Crash mantra!

How­ev­er, you shouldn’t con­fuse the Pas­sive Aggres­sive style with “con­trol­ling pro­gram flow using excep­tions”, which points to a spe­cif­ic anti-pat­tern, like this exam­ple.

I gen­er­al­ly pre­fer the Pas­sive Aggres­sive style, although it doesn’t have to be mutu­al­ly exclu­sive to the Con­struc­tivist and Tantrum styles. For exam­ple, you might leave excep­tion han­dling to a func­tion that’s high­er up in the call chain, who then in turn return a fall­back val­ue for the whole chain.

As a side note, I also dis­cov­ered a while back that there’s a non-triv­ial per­for­mance over­head asso­ci­at­ed with throw­ing (lots of) excep­tions (anoth­er argu­ment against using excep­tions to con­trol pro­gram flow) as the CLR needs to col­lect lots of run­time diag­nos­tic infor­ma­tion for each excep­tion.

And final­ly, anoth­er often-missed obser­va­tion about excep­tions is that, they are real­ly anoth­er form of GOTO.



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