Discussion on: Why Functional Programmers Avoid Exceptions

[Pragmatic Maciej]

Everything depends from the context. If you work with highly procedural code which for example does db queries (yes just calls db directly, do not use any monads and so on), then you don't work with pure functions at all, or you have them very limited, and your program is just composition of smaller programs/procedures. Therefore in such a code using Either to avoid "exploding" has really not a big sense, as to do so you need to in every such procedure just catch everything (what you did in your parseJSON example) which can explode and transfer it into Either. That ends by polluted code which naturally is side effectful but we just remove one side effect of it - error handling. In effect we have still procedural code, but code which in some level has errors as values.

Also I highly not like your comparison to Feynman, where you assume anybody who criticised your text just cannot understand what you are saying, and you able to show everything in 60 seconds video 🤷‍♂️

As said previous, that is a good idea to have value as error, but without seeing wider context we can think we live in the bubble without side effects, what very often is not true in mainstream languages. As mentioned in example, if I query the server in the function, what is already a side effect, having no exception do not make me pure function.

I also very often see Mathematics as a way to explain why FP is so better. As of course Mathematics is a background of everything we do, but really it is in background of everything humans are doing, you want it or not. FP is just simpler represent in Mathematical notation, where procedural programming is closer to original turing machine, and sequence of steps, what is also based on Mathematics 😉. So the fact that FP can be easier describe in math doesn't specially make it better.

And to be clear:

• errors as values
• referential transparency
• function composition

Are good things. But it depends from the context and project style of programming how deep we go into that. Also:

const value = parseMe(data)
const result = checkResult(value)

is the same composition like

const result = pipe(data, parseMe, checkResult)

This is exactly the same, we just have local aliases for values in first example, and we don't have them in second. Everything is about - effects and mutation, and not about syntax.

And in the end in purely FP code I would not use exceptions, as exactly how you said they are against FP. There is no argument about that. But the worst I can imagine is mixing Eithers and exceptions in one codebase, this really can end badly. And in JS/TS/Python kind of projects there is almost no way to avoid exceptions.

[Jesse Warden]

You wrap the side effects because they throw. If you didn't, they'd throw. You instead return a Result, which is composable. You can also return a Promise, which is also composeable. These aren't procedural, they're functions you can combine together like one -> two -> three or Promise.resolve(value).then(something).then(another). If you don't return a Result or a Promise, then yes, it's procedural.

Please assume benevolent intent. My comparison to Feynman was realizing I should of defined why Functional Programming eskews throwing Exceptions, and instead returns results from functions. If you don't know that context beforehand, then the ideas seem strange in async/await syntax.

If you call a server, you can return a value and have it not throw. You simple wrap the catch, and say "it didn't work". Why it didn't work is important, but beyond status code and response.ok, the fetch interface doesn't give you much. You'll have to do all that work yourself around status code, protected data decoding vs. the common response.json(). If you do that, then you have a better error message that comes out, but the function is still pure: "it works or it doesn't". The side effect, fetch, you can use Dependency Injection or the Effect pattern (or mocks to test). In Elm, there are no side effects so this isn't a problem. In ReScript, it's quite interesting; they follow JavaScript side effects model, but still strive for pure functions with "mostly" mutability. Still, even in ReScript, you'd return something like Elm: some kind of type to pattern match on like "It worked" "bad status code" "bad data" or "network error". However, you have to like the functional style and pattern matching to do that. If you don't want to do all that work in non-FP languages like JavaScript/Python, that's fine.

I'm not saying FP is better. I'm saying this style is easier for me and others. If you like it, cool, here's how you do it. If you don't, cool.

Your examples aren't the same. It's same reason Go developers are ok with if err != nil everywhere, which I get; they like the simple and explicit. You manually have to create the variables value, then manually call the function checkResult, then put the value in it, then at some point wrap some of that with a try/catch. Promises or Result.bind do all that for you without a need of try/catch.

[Pragmatic Maciej]

Promise is composable but also does eagerly side effects and if we define function as something which is referencialy transparent then Promise is not. It return depends from the "state of the world" or just depends from time. And it makes it procedure more than a function, procedure which returns some value to the caller.
Things which return value are composable but without monads doing composition with values wrapped by Either would look like your Go example where every function would check if we have left or right.

And such Either Monad allows for composition positive path totally not thinking that there is any Either and possible error.

When we look on this though we see that it is exactly simulation of procedural exception which allows code to work in positive path and just goto catch for errors. Even exactly that was one of reasons Monads in Haskell were such a thing. They allowed for pure functional composition which could do the same staff like procedural code.