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.
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.