Error Handing: — fail-fabulous

Error handling can range from failing immediately and the program stopping, to attempting to recover and proceed normally. As my experience recently has been with the RSpec test suite and its “ —fail-fast” command, I’m going to look a little deeper at that, and the methodology behind actively seeking failures.

What’s “fail fast”?

Fail fast is both a paradigm and a command.

In systems design, a fail-fast system is one which immediately reports at its interface any condition that is likely to indicate a failure.

Though ‘fail fast’ has become a popular Lean methodology (and Silicon Valley) component in recent years, the concept itself is not new. It’s analogous with the Japanese term jidoka, derived from Sakichi Toyoda’s first automated weaving loom of the start of last century, which would automatically stop the loom if a thread breakage was detected. In contemporary computer systems which utilise a fail fast approach,

when a problem occurs, [the system] fails immediately and visibly. Failing fast is a nonintuitive technique: “failing immediately and visibly” sounds like it would make your software more fragile, but it actually makes it more robust. Bugs are easier to find and fix, so fewer go into production. — Martin Fowler

There are tangible pros to adopting this mindset. As well as the above — that fewer bugs may end up in the end product if they get called out early and addressed — personally, I think the unrelenting and unabashed bashing of one’s ego when debugging serves an important purpose. May I draw your attention, dear reader, to item six of the Ten Commandments for C Programmers:

Lastly, in the modern employment tundra and especially in tech where the pace can be very quick, you have to keep up. No one will thank you for being the developer who pores over their code for days at a time when there are pull requests and updates which need to happen multiple times daily. If your team is functioning on Agile principles, you’ll need to continuously integrate. Your code and your practices have got to adapt to a modular approach — once again, break it down into small chunks and deal with the errors as they present.

To me, the kintsugi of debugging gives a better-crafted end product and a more humble developer.

On to RSpec

Rspec is a testing framework for Ruby code, and it means you can use ‘test-driven development’ (TDD). In this way, you can break down your code into smaller chunks and test each bit. If your car breaks down, you take it to the mechanic and they find the specific part which needs a stratospherically expensive replacement, right? Same idea — but now you get to be the mechanic, even write your own tests. I would write more here, but some superb human has already written a great post on everything RSpec.

There’s nothing worse than a test ‘silently failing’ when debugging. It sorta looks like it’s working, it feels like it’s working…. on closer inspection, it’s definitely not working. And there’s no error message.

The beauty of using test-driven development is that when something isn’t working, if you’ve written a lot of modular tests, you’ll get back a whole slew of detailed messages. This is very useful, especially if a lot of tests are failing because of one specific thing affecting multiple moving parts, but can sometimes be overwhelming.

` — fail-fast`

…is a command in RSpec which allows you to just get back the first error and its details. Nothing else. As Jeff Kreeftmeijer explains:

The fail_fast option will cause RSpec to immediately stop running your specs and output the failure details whenever it fails for the first time, giving you a nice speed boost when trying to fix some spec fails.

RSpec.configure do |c|
  c.fail_fast = true
end

I guess it’s kind of like a To Do list, right? If you try and put the whites wash on, do the washing up, call your mother and paint your nails at the same time, you’re neither being fully present for a task nor using your time the most efficiently. Heck, if you’re not neurotypical, multi tasking could even be bad for you.

In fact, there are countless arguments against and studies discussing how multi-tasking impairs productivity, quality of life, and mental health. In my case, switching from a whole hessian sack of wriggling, live errors to scrutinising just one has been 90% process — helpful. There’s still the 10% of times when I want to see the bigger picture and get a context for the single error, not to mention see how many times I’m going to have to repeat the debugging process, but it’s been a very useful approach. However, there’s even a bit of flexibility in this, too; you can explicitly flag how many errors to return if you know some are bunched or related, using an equals and integer. For example, this will give you the first three errors:

--fail-fast=3

So while it needn’t be the only way to debug, as it’s fairly myopic, it’s a great tool to have. There is also an argument for applying ‘fail fast’ methodology when in development mode, and ‘fail safe’ in production mode (C. Neumanns, 2016) which highlights the difference in threshold of fault tolerance between these two stages — useful for a beginner to start considering, especially when we start considering our users and their experience.

I’ve written elsewhere about my stupendously impressive inability to read what’s right in front of me with error messages. Looking at just one error really helps me focus, and look at all the information, rather than just skimming. (It also allows me to appreciate that all the seed data on the Learn platform, previously unnoticed by me, is either famous cats, Leeroy Jenkins, Devin Townsend or something similarly super). The chances are I can try and work it out from this information instead of getting exasperated and asking for help immediately.

PS: for added sass, you can also get a nyan cat inspired RSpec formatter.