If you enjoy reading these exercises then please buy Crista’s book to support her work.
Style 21 – Tantrum
- Every single procedure and function checks the sanity of its arguments and refuses to continue when the arguments are unreasonable.
- All code blocks check for all possible errors, possibly print out context-specific messages when errors occur, and pass the errors up the function call chain.
Last week we looked at the Constructivist style where we provide fallback values wherever possible to allow the program to continue in the face of an anomaly. The Tantrum style we’ll look at today is the opposite.
In this style, any invalid input or error will be met with an exception that terminates the program flow, as you can see from the functions below.
This approach to Fail fast, Fail loudly has often been heralded as a desirable characteristic of a fault-tolerant system. For us developers, it’s also the easy way – we don’t have to think about fallback strategies which can be a challenge on its own, and sometimes there might not be a good fallback strategy at all.
But as we discussed in the last post, adopting a well thought-out fallback strategy can have a massive impact on the user experience. And as Jeff Atwood wrote a long time ago (and it’s still applicable today), the most important consideration should be the needs of your users.
If we adopt a “fail as often and as obnoxiously as possible” strategy, we’ve clearly failed our users. But if we corrupt or lose our users’ data through misguided attempts to prevent error messages– if we fail to treat our users’ data as sacrosanct– we’ve also failed our users. You have to do both at once:
- If you can safely fix the problem, you should. Take responsibility for your program. Don’t slouch through the easy way out by placing the burden for dealing with every problem squarely on your users.
- If you can’t safely fix the problem, always err on the side of protecting the user’s data. Protecting the user’s data is a sacred trust. If you harm that basic contract of trust between the user and your program, you’re hurting not only your credibility– but the credibility of the entire software industry as a whole. Once they’ve been burned by data loss or corruption, users don’t soon forgive.
The guiding principle here, as always, should be to respect your users. Do the right thing.
You can find the source code for this exercise here.
I’m an AWS Serverless Hero and the author of Production-Ready Serverless. I have run production workload at scale in AWS for nearly 10 years and I have been an architect or principal engineer with a variety of industries ranging from banking, e-commerce, sports streaming to mobile gaming. I currently work as an independent consultant focused on AWS and serverless.
Here is a complete list of all my posts on serverless and AWS Lambda. In the meantime, here are a few of my most popular blog posts.
- Lambda optimization tip – enable HTTP keep-alive
- You are thinking about serverless costs all wrong
- Many faced threats to Serverless security
- We can do better than percentile latencies
- I’m afraid you’re thinking about AWS Lambda cold starts all wrong
- Yubl’s road to Serverless
- AWS Lambda – should you have few monolithic functions or many single-purposed functions?
- AWS Lambda – compare coldstart time with different languages, memory and code sizes
- Guys, we’re doing pagination wrong