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.
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.
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.
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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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
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.
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.
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.
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.