The Art of Exception

English is an area of in­ter­est lit­tered with edge cases. In prepa­ra­tion for ad­dress­ing sim­i­lar prob­lems in the de­vel­op­ment of the Harper Chrome ex­ten­sion, I’m spend­ing some time here re­flect­ing on what I’ve learned by tack­ling the com­plex maze of English edge cases.

Harper is not alone, and there’s a real chance that you’ll have to work on ex­cep­tion-tol­er­ant code. In that case, you will need to un­der­stand the why for some of the de­sign de­ci­sions you en­counter in the wild.

What Do I Mean By “Edge Case”?

An edge-case is a sit­u­a­tion (that is of­ten con­text-de­pen­dent) which re­sults in in­cor­rect be­hav­ior from a model, pro­gram, or the­o­ret­i­cal frame­work. In con­ver­sa­tions about the Harper Chrome ex­ten­sion, an “edge case” is where the ex­ten­sion im­prop­erly reads from or writes to a site’s em­bed­ded text ed­i­tor.

Most sites use <textarea /> or <input /> el­e­ments for text edit­ing, but a num­ber of sites (including WordPress, as you know) have com­plex WYSIWYG ed­i­tors. Each be­haves dif­fer­ently, which can cause prob­lems with the afore­men­tioned read/​write loop. The prob­lem: our users ex­pect us to sup­port all ma­jor text ed­i­tors.

Err on the Side of Inaction

In Harper’s core al­go­rithm, we err on the side of false-neg­a­tives. This de­ci­sion was de­rived from an ob­ser­va­tion made early on in the pro­jec­t’s life cy­cle: peo­ple usu­ally blame them­selves for their own writ­ing mis­takes, un­less the er­ror is truly triv­ial.

All in, we get far more com­plaints about false-pos­i­tives than false-neg­a­tives. Which is why we err on the side of in­ac­tion. If the al­go­rithm thinks it’s pos­si­ble, but not cer­tain an er­ror was made, we sup­press the re­port in case Harper is wrong.

In the Chrome ex­ten­sion, we will be ex­em­pli­fy­ing this rule by only en­abling it on a cu­rated list of do­mains by de­fault.

As site vis­its tend to fol­low a Pareto dis­tri­b­u­tion, we can cover most traf­fic with just a few items in this list.

Make Tweaks Easy

When an edge case (which is al­most al­ways a false-pos­i­tive) ap­pears in Harper’s core al­go­rithm, it’s usu­ally in a pretty ob­vi­ous spot. This is be­cause we as­so­ci­ate each lint out­put with a spe­cific, easy-to-find mod­ule the core code.

In most cases, this is not ver­bose, spe­cial­ized Rust code. Rather, it is an LLM-friendly DSL that is leg­i­ble to most with even be­gin­ner-level pro­gram­ming ex­pe­ri­ence. This com­bi­na­tion of easy-to-read and easy-to-edit makes con­tri­bu­tions from the com­mu­nity (regarding edge-cases) com­mon­place.

I aim to repli­cate this suc­cess in the Chrome ex­ten­sion’s read/​write ca­pa­bil­i­ties by care­fully doc­u­ment­ing the ar­chi­tec­ture and work­ing with third-par­ties to make the con­tribut­ing process clearer and eas­ier.

It Is an Art

There is a rea­son I call this an art. Design de­ci­sions in ex­cep­tion-tol­er­ant sys­tems stem from these two sim­ple ideas, but they grow from an in­tu­ition de­vel­oped by their main­tain­ers. I’m not ex­actly sure how the Chrome ex­ten­sion will grow to han­dle edge cases. I’ll be sure to come back here and de­tail them when I do.