Clojure Tip 💡
Special thanks to Richard Barker for this tip!
Let’s continue on our theme of exception handling. You should use the
catch statement’s built-in dispatch to have different behavior for different exception types.
Richard mentioned seeing code that catches an
Exception then checking its type to decide on its behavior. I’ve seen this myself. Here’s an example:
(try (clojure.java.io/reader "/tmp/file.txt") (catch Exception e (if (instance? java.io.FileNotFoundException e) (println "File not found") (throw e)))) ;; unknown exception so re-throw
catch expressions in a
try have built-in type-based dispatch, so this extra instance check is redundant, and quite possibly many times less efficient, than the following code:
(try (clojure.java.io/reader "/tmp/file.txt") (catch java.io.FileNotFoundException e (println "File not found")))
The reason the
catch expression starts with a class is because it is looking to match only instances of that class. You can have multiple
catch expressions to have different behavior for different kinds of exceptions.
If you can have multiple
catch expressions, then there must be some rules for choosing which one applies. The rules are simple. The JVM checks each catch expression, in order. If the expression in question is an instance (direct instance or instance of a subclass) of the given class, then it’s a match. The search stops, and the code is run. If the JVM gets to the end and no match was found, the exception is not caught and it continues to bubble up the stack (to the code that called this). That’s why we don’t need to re-throw the exception. We are selecting only
FileNotFoundExceptions. All other exceptions pass through.
These rules lead to a good rule of thumb: catch the most specific exception first. If you have multiple catch statements, they are checked in order. That means that if you have a superclass before its subclass, the subclass’s
catch will never fire. Let’s make it concrete:
(try (clojure.java.io/reader "/tmp/file.txt") (catch java.io.IOException e (println "Some kind of IO Exception")) (catch java.io.FileNotFoundException e ;; this will never catch!!! (println "File not found")))
FileNotFoundException is a subclass of
IOException will always match for
FileNotFoundExceptions. Reverse the order to put the most specific one first.
Book update 📖
The book is selling well, according to the publisher. They are hard at work getting Chapter 4 ready. I imagine it will be released any day now.
This makes immutability a discipline instead of a language feature. I hope that the difficulty of applying the discipline will encourage people to check out languages that are immutable by default.
You can buy the book and use the coupon code TSSIMPLICITY for 50% off.
Currently recording 🎥
Woohoo! I did it! After several attempts and lots and lots of preparation, I recorded and published the lesson about Testing Distributed Systems.
In the lesson, we develop tests for a distributed key-value store that I wrote. Even though I had rehearsed the lesson before recording, running the code many times, I still found a bug in the key-value store client during the recording. Distributed systems are hard!
We start off with an easy test to make sure the system is eventually consistent. Then we develop a model-based test of the system. The challenges are many: it’s asynchronous, we can’t introspect into the server, and the outcome depends on the order the clients sync to the server. There’s lots of indeterminacy in the system, and we have to model that with a set of possible states. When that set is empty, it means there’s no way to get what we have (according to the model), so we have a failing case.
Along the way, we learn lots of lessons, like how to ensure we get reliable failing cases, how to test our tests at the REPL, and how to interpret our results.
Property-based Testing course is winding down now. There are several more lessons planned, including how to test a system that doesn’t use Clojure, Spec integration, and how to use PBT during design to make sure you don’t violate any invariants.
Brain skill 😎
If you’re reading this newsletter, you’re probably a fairly autonomous learner. Even still, it’s worth exploring how autonomy helps us learn.
Autonomy in learning means that we are able to take charge of our own learning. Unfortunately, many of us were not given much autonomy in the years of schooling we went through. The next lesson, assignment, or project was chosen for us. Even when we were given a choice, we weren’t taught how to make that choice.
Once you’re out of school, you’re on your own. What should you learn? What do you want to learn? Why do you want to learn it? These are all questions that help us explore our autonomy. Yes, in the short term, learning on our own is less efficient. It’s so much more direct to be given exactly what you should learn next. But this assumes the teacher assigning it to you knows exactly what you need. Who can give such personalized attention? Maybe a personal tutor, but not a teacher with a class of 20-40 students.
No, we have to take charge of our own learning, even though we will go down dead ends and make wrong turns. In the long run, it is more efficient. We learn things that relate to a sense of purpose. We learn things we are curious about. We learn when we are ready (not at the ring of a bell). And we learn the way we learn best.
How can you develop this skill? You must learn to set goals, following you motivation and finding purpose. You must have the self-awareness to know your own learning process. And you must be able to plan your learning by applying appropriate learning strategies.
But, like I said, if you’re reading this, you’re probably ahead of the autonomy curve. You did choose to receive this newsletter, which already shows a lot of initiative.
Clojure Challenge 🤔
Last week’s challenge
The challenge in Issue 346 was to make a higher-order function that implements exponential backoff.
You can check out the submissions here.
This week’s challenge
delete from a vector
Clojure’s vectors let you efficiently get a value given an integer index. Often, I want to remove a value from a vector at a certain index. This doesn’t exist in the core library, so I wind up writing it each time. The question is how to do it in an efficient way?
Here’s the task: write a function
delete-at that takes a vector and an index and returns a new vector with the item at the index removed. The new vector should be one shorter than the argument.
(defn delete-at [v i] ;; your code here )
Please be mindful of the efficiency of your solution.
As usual, please send me your implementations. I’ll share them all in next week’s issue. If you send me one, but you don’t want me to share it publicly, please let me know.