With result/either you are forced to handle the error very close to where it happend. With exceptions (in my understanding) the goal is to be able to handle err

With result/either you are forced to handle the error very close to where it happend. With exceptions (in my understanding) the goal is to be able to handle errors much further up the stack. But in such cases you aren't sure where the exception originated, so you need to encode that in the exception to understand the error. If you do very close exception handling, you lose what I consider to be 'the point of exceptions'. Hence I don't think that should be done. The core of my argument is then that error handling beyond 'just retry' needs a lot of detail about the error. And I believe this detail is easier to encode if the error handling is close to the error. Since exception handling is meant to be further away from the error, it isn't as suited to this kind of error handling.