If you are a Rust or Kotlin developer, be careful of neck strain from too much nodding along as we look at patterns that increase verbosity (at the right place, I’d suggest) and promote correctness.
Some backstory
I started out professionally in the salt mines of C# and Java. In those days, generics were new and not widely adopted. A common debate back then was "exceptions: checked vs unchecked?" Passionate and respected people differed greatly over this point, and the outcome, at least in Java, has been a uniform mess. I cannot begin to count the number of bugs I resolved that boiled down to someone forgetting to catch and handle a relevant exception, or a new exception type being added without every consuming call site and stack being carefully inspected. As an early contribution, I wrote and then passionately advocated for years for the removal of the terrible logAndThrow() function, which codifies one of the worst ways to handle exceptions.
Later, I spent a few years deep in C++. Exceptions in C++ are problematic, and we disabled them altogether to our great benefit. This immersion therapy in thought-out and comprehensive software along with the "default exception"—the omnipresent guillotine of the segfault—set the stage for a pensive return to the JVM at Momento.
The Momento story
At Momento we use gRPC, and for many internal services we use Kotlin. In case you're not aware, Kotlin is a programming language that compiles down to JVM bytecode—reminiscent of TypeScript's relationship to JavaScript in a number of ways.
Setting the direction for a greenfield service, I needed a way to ensure that, over time, bugs are "interesting" instead of mundane gotchas for well-meaning developers (like future me) to blunder into. Placing the burden of some mandate like "you must catch the stuff you call into" or "read every line of everything you call to know what you need to catch" seemed like a great way to waste everyone's time. Developers, as it turns out, are good at writing code, and written code is reasonably well-correlated with value. I want to encourage value, so enabling developers to write better code faster instead of reading and tip-toeing everywhere is a no-brainer for me.
The direction
(At least) 2 key technical maxims need to be agreed on:
- Software should lean on the compiler to purge "illegal" code
- Common bugs should be "illegal" to write (functional programmers unite!)
One of the simplest examples of this is when a compiler prevents you from using a variable that was not initialized. This is common across JVM, dotnet, Rust and many other ecosystems. While we could instead rely on the compiler generating code that throws an exception when it encounters the use of an uninitialized variable (laughs in C++), we enjoy the guarantee that no uninitialized variables will be read anywhere in our applications (modulo unsafe blocks, creative reflection, and the like—but we're talking about guard rails and rules, not The Universal Model Of Everything). This guarantee is so valuable and intuitive, developers will fix code that does not comply with it. Here's an example you'll want to fix:
Now, Kotlin types are also aware of possible-nullity so this can be repeatedly simplified to remove cognitive burden for readers and make this code rely more and more on the compiler for static legality verification:
We can declare message as a readonly (val vs var in Kotlin), so if I want to use message after this conditional expression (yes I'm foreshadowing the next update here), the compiler will guarantee the variable was certainly initialized before my use—or it will declare the program as illegal and will fail to compile, which is good!
For completeness, since we're using Kotlin here we should lift the assignment to make this a clean and error-resistant declarative expression instead of an imperative, temporally vulnerable expression sequence:
On exceptions
Oh yeah, this is what this is supposed to be about. Exceptions are, if you squint (to be honest, I don't think you really need to squint), gotos by another name.
One hilarious trick I've seen used by teams that decry goto in languages that support it is to use the do {} while (false); pattern. This gives you both a break label and a continue label you can goto at will! This is a terrible thing to do. Future readers will be confused and will have to reason about scopes and original intent—and heaven help them if the original author has implemented a dynamic break counter to bounce out of successive wrapped label-loops.
Now, to be fair, the problem itself is not the *Exception—*the issue here is the throw or raise statement. Exceptions themselves are great. A stack trace bundled with helpful debug information? What's not to love? Assuming we have agreed on the technical maxims above: When you goto nearest_wrapping_catch_expression_on_the_stack_which_catches_a_type_contravariant_of_this_exception_type in your library code, you have just installed a bug in your users' software. That label is unreadable—but that’s what more or less what throw does!
Consider an API you might vend (to your teammates, to your customers, to $future_you) that gives back a random number most of the time, but say we think there's a bug with the random number generator for very large values:
This will usually work in tests, and it might work for months in production without any catch label. However, it is trivially easy for your users to write an obvious bug with this API design. Folks who don’t read the code will expect this function to always return a random number because it is easy and it compiles:
Tragically, it ignores that “very important” facet in your API where you distrust large values of nextLong(). You will cause your users to crash now and then as a consequence.
Instead, consider how it would look if you were to use your language's features to help your users correctly call your special function:
This takes more code to write, so why bother? Well, as a good API developer who cares about their users more than they care about themselves, you have now exposed all possible valid return values from this function to the type system so your users' compilers ensure they don't have bugs while using your function. Their naive delay(randomNumberUsually()) invocation now will not compile, because they have not handled that crucial rare occurrence of large entropy values.
Here's what your user will do with that function now:
They must consider both cases in order to use the value. They can opt out of handling many other cases with an else -> if they only care about 1 result, and it’s guaranteed that no rogue goto dynamic_catch_label will bomb their application unless there is a real bug that you never considered, like ThreadLocalRandom::current() failing. If it fails a lot you might consider catching it internally and modeling it instead as a clean, typesafe return value.
If they encounter the exception bug and realize they need to catch AskMeAgainException later they'd end up with:
The rule
Your errors are not special; they are return values. Never raise exceptions across component boundaries.
Nakedly invoke your components without try{}, and allow bugs to propagate outward in the manner of a segfault to either crash the program or log an unhandled bug at the very top. Provide components that are safe to invoke without try{}.
Within a component you might use tools—language features or libraries—that throw exceptions. That's fine; you need to catch them and model your component's return values. You don't need much more than Ok<T>(value) and Error(exception) in the general case. Returning to where you were called with an error is far kinder to your user than issuing a dynamic goto to an unknown label they may not have even provided.
(What is a component? I leave that up to your good judgement. It could be a method, a function, a class or something else; but generally, the tighter-scoped your components are, the better the compiler will do at static verification.)
What do popular languages do?
Some languages already have built-in affordances for this; some have fairly recently expanded support for the paradigm. I certainly did not invent this idea, and here’s some evidence of that in addition to the Kotlin above:
In Rust, you cannot escape Result<> and Option<>. You could call .unwrap() and panic your program, but that would be a sad thing to do! Instead just use the Rust ? operator and cascade a Result upward from your possibly-erroring function. The ? operator is basically a special case of pattern-matching explicitly intended for error handling. It supports following a well-behaved stackwise unrolling of failures until something handles it or drops it.
Go has a similar view on error handling as the new multi-language Momento position and it shows up in Go’s idioms. They have an error type, and even the linked 11-year-old blog illustrates how useful it is to advertise the error-semantics of one’s frameworks. Notwithstanding the rest of the language, I certainly like Go’s error handling philosophy.
C# added a neat switch branch matching expression in 8.0. They have some unfortunate handling of enum values due to int/enum interchangeability but they’re trying, and the language is better for it!
Even Java has embraced pattern matching constructs suitable for safe errors-as-return-values with their new structured typecasting instance of operator. While generally applicable to all kinds of downcasting, this is particularly powerful for ensuring your APIs are predictable and well-behaved in your users’ runtimes.
The C++ community is currently working on pattern matching constructs. The likes of Bjarne Stroustrup and Herb Sutter are talking about this. The writing is on the wall, and soon we’ll have some construct for matching. You could use workarounds available to the language today like variants (std::get, std::holds_alternative), and I would encourage you to do so in the meantime. The discussion for this feature is subtle but if you’ve got some patience it’s a worthwhile topic. Grab some tea and have a view of a particularly interesting demonstration. This talk even mentions the C# implementation of switch and can help you understand at a deeper level what the whole idea in this blog is about.
Pros and cons
Pros:
- Your users will have fewer bugs (in many languages). Code validation is pushed forward to the compiler to statically verify that every known path is handled. This is "cooperative development" with your users as opposed to exception style "antagonistic/gotcha development."
- Your users discover and account for edge cases early.
- Your users do not litter try/catch everywhere to try to outsmart your throws.
- Your users' call sites (rather, their usage sites) are explicit, clear, and safe; the compiler enforces this for them.
Cons:
- You sometimes type more with Exceptions Are Bugs philosophy (you have to choose sealed types and model your function's return value domain).
- Your users might type more. Common IDEs auto-generate pattern match arms in many common languages though, and if those users need the happy case result they probably should make a choice about what to do with the sad case anyway (see Rust, Kotlin, Go, C++, and Java).
- Some languages do not yet have a great answer for pattern matching.
- Some people like exceptions. (This philosophy does not wall them off. As an exercise for the reader, can you figure out how you could add an getOrThrow() to RandomNumberUsually above?)
Closing thoughts
When you're in the weeds writing some code, a network error or a slow disk might seem like the end of the world to you. That’s natural. However, when you're done and move on to employ that code to solve a higher-level problem, you may no longer care about those possible issues—or you may have a different opinion about how important those issues are.
In Rust, sometimes people call unwrap() on an Option which might be None: If you do this in a library, you're forcing a dynamic panic onto your users when they might have workarounds just in case your library isn't working (I.e. your errors are not so special that you should crash your users over them).
For the cost of some additional boilerplate code, your users (remember: peers, external or future you) receive the benefit of "obviously correct" code that, to the greatest degree possible, works if it compiles. Like Rust tries so hard to do. ❤️
Let me know what you think—join the Momento Discord!
