DEV Community

Discussion on: What is the benefit of Functional Programming?

Collapse
mortoray profile image
edA‑qa mort‑ora‑y

Exceptions in no way violate the contract of a function, they are merely part of the contract. There is no fundamental reason a pure function could not throw an exception.

I've covered this in my article: The exceptional myth of non-local flow

Collapse
kspeakman profile image
Kasey Speakman Author

In functional languages, pure functions depend on the function signature to be a declared contract. An exception is not declared in the signature. Some functional languages do not even have exceptions. With the examples in your article being in C, I'm not sure that our points of view are looking at the same set of circumstances. If we were talking about C, I might be swayed to your side.

Collapse
mortoray profile image
edA‑qa mort‑ora‑y

I'm saying that exceptions in general don't prevent something from being a pure function. I don't belive it makes a significant difference whether the error handling is explicit or implicit -- it can be considered part of the contract either way.

For example, in my language Leaf, errors are an implicit part of the signature, they can however be turned off.

Thread Thread
kspeakman profile image
Kasey Speakman Author

We will have to agree to disagree then. I think any error handling strategy could work in its own set of conditions. But to say that exceptions are the best way to handle errors across the board, I can't agree with.

Thread Thread
seykron profile image
seykron

In web environments you usually have one or two options to manage errors: retrying IO or returning an HTTP status code 500. There's a user in the other side waiting for a reply, and in the most common request handling model thread-per-request there's a thread bound to the current request waiting to be released. So you can either choose to handle the error flow like a special flow in your business logic (like Try's in scala), or you just can throw an exception, set up a catch-all handler and return a friendly error code so the user can retry the operation.

I really don't support error flows in web environments, it usually opens additional branches in the execution that makes harder to debug and detect errors. The easiest way I know to debug and fix errors is to throw exceptions closer to the place the error occurs.