Exercises in Programming Style–Constructivist

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 Con­struc­tivist style today.

 

Style 20 – Constructivist

Constraints

  • Every sin­gle pro­ce­dure and func­tion checks the san­i­ty of its argu­ments and either returns some­thing sen­si­ble when the argu­ments are unrea­son­able or assigns them rea­son­able val­ues.
  • All code blocks check for pos­si­ble errors and escape the block when things go wrong, set­ting the state to some­thing rea­son­able.

 

So far we have neglect­ed error han­dling on pur­pose, but not any­more. The next few styles will focus on error han­dling and illus­trate the sub­tle dif­fer­ences between a few dif­fer­ent strate­gies.

In today’s style, we’ll be mind­ful of errors but pro­vide sen­si­ble fall­back val­ues wher­ev­er pos­si­ble so that the pro­gram can con­tin­ue.

Take the extract­Words func­tion below as an exam­ple, when we’re giv­en invalid input we return a sen­si­ble fall­back val­ue (in this case the emp­ty array) instead of throw­ing an excep­tion.

Sim­i­lar­ly, if we’re not able to open the input file (per­haps the file doesn’t exist), rather than throw­ing an excep­tion and ter­mi­nat­ing the pro­gram flow, we return an emp­ty array instead so the pro­gram may con­tin­ue.

Style20_01

We’ll apply the same approach to deal­ing with anom­alies in the removeStop­Words func­tion here. If we are unable to read the file with all the stop words for what­ev­er rea­son, we’ll return the input words in its entire­ty as if the stop words file was emp­ty.

Style20_02

And the same goes to the oth­er func­tions.

Style20_03

Final­ly, we string every­thing togeth­er in a pipeline.

Style20_04

 

When applied well, the Con­struc­tivist style to deal­ing with errors can have a pos­i­tive impact to user expe­ri­ence in user expe­ri­ence.

For exam­ple, browsers take a very Con­struc­tivist approach to ren­der­ing HTML pages — it’ll do the best job it can even when images, css, js scripts or oth­er resources the page depends on is miss­ing.

Sim­i­lar­ly, Netflix’s Hys­trix library has a built-in sup­port for fall­back com­mands so that you can grace­ful­ly degrade the user expe­ri­ence dur­ing excep­tion­al cir­cum­stances.

For exam­ple, when you exe­cute a Hys­trix­Com­mand to load the movie list for a user:

  1. try to load movie list based on user pro­file (pref­er­ences, watch his­to­ry, etc.)
  2. User­Pro­file ser­vice is non-respon­sive
  3. fall­back to fetch gener­ic movie list for UK
  4. gener­ic movie list for UK not avail­able due to DB out­age
  5. fall­back to hard­cod­ed movie list from the service’s con­fig file

which is a whole lot bet­ter than the whole app crash­ing when­ev­er any of the depen­dent ser­vices is not respon­sive! (appar­ent­ly that’s how things were at Net­flix in the ear­ly days)

 

On the oth­er hand, when you give fall­back val­ues to the user with­out noti­fy­ing them it can also cause a lot of con­fu­sion.

For exam­ple, if I had a typo in the path to the stop words file, this will be the out­put of my pro­gram:

the — 4507

to — 4243

of — 3728

and — 3658

her — 2225

i — 2070

a — 2012

which would not be what I was expect­ing.

For­tu­nate­ly, in this case we do inform the user of the error so that they’re able to rea­son about the unex­pect­ed out­put from the pro­gram.

Style20_05

We could have done bet­ter though, by inform­ing the user that “due to error open­ing the stop words file, all words from the input file will be count­ed”.

There are many oth­er sit­u­a­tions where an explic­it error might be bet­ter. A few of the JS exam­ples from Gary Bernhardt’s WAT talk springs to mind! 

 

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