39
Why Functional Programmers Avoid Exceptions
If you’re in a hurry, here is the 60 second version:
My previous article caused a variety of consternation, imperative patriotism, and lots of nuanced follow up. It reminded me of when Richard Feynman was asked to define how magnets work and he refused. The perturbed interviewer postulated it was a reasonable question in hopes to understand why Mr. Feynman wouldn’t answer it. Richard Feynman covered a variety of reasons, 2 of which were:
In the case of avoiding async/await keywords in JavaScript, this makes a huge assumption you know about Functional Programming, Imperative, exception handling, how various languages approach it or don’t, the challenges between dynamic and strongly typed languages, and on and on.
In this article, I wanted to remedy that and focus on the deeper reasons why, specifically being pragmatic around how Functional Programmers get things done vs. the theory or why’s. This means understanding:
In investigating specifically why exceptions aren’t preferred in Functional Programming, I found out, they aren’t actually anti-functional programming. Worse, I found out many argue they do not violate pure functions or referential transparency with a lot of fascinating supporting evidence. A few argue they aren’t even side effects. It gets more confusing when you start comparing strictly typed functional languages vs. dynamic ones, or practicing FP in non-FP languages.
In practice, exceptions, like side effects, seem to violate all the reasons why you use pure functions: Your code is predictable, easier to test, and results in better software. Exceptions ensure your code is unpredictable, reduces the value of the tests, and results in worse software. Yet that’s not what the mathematical definitions say. They don’t agree, nor disagree with my assertions; rather they just say that known exceptions do not violate referential transparency. Yes, there are detractors. Regardless, this really shook my faith.
One could say these are pedantic; citing the true definition of referential transparency the mechanisms behind how Exceptions can or cannot negatively affect it, and thus possibly not violate pure function rules. However, this is the common problem between scientists and engineers: while scientists will give you the Mathematicians Answer, they won’t help you do your actual job.
And that’s what brought me back to reality. I’m not here to debate semantics, I’m here to deliver working software. However, I will cede to nuance if someone wishes to delve into the relationships between the mathematics behind these constructs. So far, preferring mathematical style programming over Imperative or Object Oriented seems to be going much better in delivering better results even if I don’t have a 100% iron clad understanding of all the nuances of the rules.
The good news, despite finding deep nuance around exceptions and their complicated relationship with the mathematical purity of FP the industry, both FP and others (i.e. Go, Rust, Lua) has basically accepted the pragmatic truth: exceptions aren’t pure, act like side effects, and aren’t helpful when writing software. We already have a solution: returning the errors as values from functions, using Result (or Either) types.
Keep in mind, the above has a Haskell bias. I encourage you to google “Exceptions Considered Harmful” and see some of the horrors that can arise when exceptions put your stateful code (Java/C#/Python/JavaScript) into a bad state.
When people say prefer pure functions it’s because of the following reasons:
What does that mean, though?
We say predictable because you call it and it returns a value. That’s it.
const isAnOk = safeParseJSON('{"foo": "bar"}')
const isAnError = safeParseJSON('')When you bring exceptions into it, you now have 2 possibilities: it either returns a value, or blows up.
const result = JSON.parse('') // result is never used/setWhen you combine functions together into programs, the program takes a value and returns a value. That’s it.
When you bring exceptions into it, you now have X * Y possibilities: the program either returns a value, or X number of functions possibly explode in Y number of ways; it depends on how you wire the functions together.
This exponential complexity shows just how unpredictable code can be with exceptions.
Easier compared to what? How?
Pure functions don’t have side effects, so you don’t have to setup and tear down stubs or mocks. There is no initial state to setup, nor state to reset afterwards. There is no spy that you have to assert on after you call your code.
Instead, you give your function an input, and assert the output is what you expect.
expect(safeParseJSON('{"foo": "bar"}')).to.be(Ok)
expect(safeParseJSON('')).to.be(Error)Compared to what? What does “easier” mean? Easy for someone familiar with the code? This statement is too nebulous and full of feelings.
Still, many would agree, regardless of language, that code that doesn’t have any side effects is a lot easier to deal with and change and unit test over 6 months of the code growing compared to one that has a lot of side effects that you have to account for, test, and learn about their possible exponential changes in the code.
If you prefer pure functions, that means very little side effects, or they’re on the fringes of your code. But then how do you handle things that go wrong? You return if the function worked or not. If it worked, it’ll have the data inside. If it failed, it’ll have a reason why it failed. In FP languages they have a Result or Either type. In languages that don’t have this kind of type, you can emulate in a variety of ways. If the code works, you return an
Ok with the value in it. If the function failed, you return an Error with the reason why as a string clearly written in it.const safeParseJSON = string => {
try {
const result = JSON.parse(string)
return Result.Ok(result)
} catch(error) {
return Result.Error(error?.message)
}
}Many languages have embraced the Promise, also called a Future, way of doing things. Some languages have used this to also handle asynchronous operations because they can fail in 2 ways that mean the same thing: it broke or it timed out. For example, most people aren’t going to wait 10 minutes for their email to come up, so you typically will see failures within 10 to 30 seconds even though technically nothing went wrong; we just stopped trying after a set amount of time. JavaScript and Python’s versions don’t have this timing built in, but there are libraries that allow to use this behavior.
This results in pure functions that always return a value: a
Result. That can either be a success or failure, but it’s always a Result. If it’s a failure it won’t break your entire program, nor cause you to have to write try/catch. While Promises can substitute in for a Result in JavaScript for example, ensure you are using the Promise itself, and not the value it returns via async/await. That completely bypasses the built-in exception handling, and forces you to use try/catch again.The way you build FP programs is through combining all these pure functions together. Some can be done imperatively, sure, but most are done via some type of railway oriented programming. There are variety of ways to do this in FP and non-FP languages:
This means, in ReScript and F#, you’ll have a function, and a Result will come out. You can then see if your program worked or not.
let parsePeople = str =>
parsePeopleString(str) // <-- this function could be an Ok or Error
-> filterHumans
-> formatNames
-> startCaseNamesFor JavaScript/Python, it’s a bit more nuanced around the types. For Python, we’ll assume you’re returning a Result in PyMonad or Returns.
def parse_people(str):
return parse_people_string(str)
.then(filter_humans)
.then(format_names)
.then(start_case_names)For JavaScript, unless you’re all-in on some kind of library, natively you can do this using Promise. Promise is already a type of Result: it holds a value, and if it worked, you can get it out using then, else the failure via catch. They’re also composable by default so you can create Promise chains that automatically unwrap
Promise values, use regular values as is, or abort to the catch in case of an error. You lose that ability once you start using async await because now you’re responsible for:For Promises, you just return a value or another Promise and it just comes out the other end ready to go. If not, you’re catch will handle any errors. This ensures whatever function calls your Promise chain itself is pure because it always returns a Promise value.
2 huge assumptions:
If some functions aren’t asynchronous, most JavaScript programmers would think they can just return a Result type instead to keep it synchronous. There isn’t a huge penalty in speed/memory to using a Promise, but some would prefer to use a Result instead. I’d suggest to 2 things if you’re not using a library: favor a Promise over a Result. A Promise is native and basically acts like a result already.
const parseJSONSafe = string => {
try {
const result = JSON.parse(result)
return Promise.resolve(result)
} catch(error) {
return Promise.reject(error)
}
}If, however, you’d prefer to make a clear delineation between an async operation and a possible failure scenario, then you’ll have to unwrap it at the end of the promise chain, similar to Rust or Python’s dry/returns. There are many helper methods on how to do this based on what Result library you’re using. We’ll use Folktale below. Here we’ve defined a safe wrapper around
JSON.parse:const parseJSONSafe = string => {
try {
const result = JSON.parse(result)
return Ok(result)
} catch(error) {
return Failure(error)
}
}When using it, it’ll come out the next Promise’ then and we can pattern match to get the error or value out and convert to a normal Promise.
const parse = () =>
fetchJSON()
.then(parseJSONSafe)
.then(
result =>
result.matchWith({
Failure: ({ value }) => Promise.reject(new Error(value)),
Ok: ({ value }) => Promise.resolve(value)
)Functional Programmers avoid exceptions because they basically act like side effects, tend to feel like they’re violating pure function rules in regards to having no return value and possibly crashing our program. If you instead favor pure functions, return a Result type when things can possibly fail. You can then use your language’s preferred way of composing functions together. Then you have pure programs that have an input and an output. This means both the functions, and the program itself, are much easier to unit test. You no longer have to write
expect(thisThing).throws(SomeExceptionType). You don’t have to write try/catch/throw in your code. You just give your functions or program and input, and assert on that output.For side effects, if you can’t force them to return a meaningful value, then you can just assert they were called with your expected inputs via Sinon’s spy methods or TestDouble’s assert method. There is no longer indirection, no longer a need to use to try/catch in multiple places for your code. This makes your functions and program much more predictable, especially when you combine many functions together.
For native functionality in non-functional languages like JavaScript and Python, you wrap the unsafe code. In the above examples, we wrapped JSON.parse with a try/catch and have it either return a Result or Promise. In FP languages, that would already return a Result. If you’re programmatic, languages like ReScript and F# support both Result types AND pattern matching on exceptions (which I think is blasphemy).
39