> And that's not something you do thanks to try/catch. You just handle the error where it's meaningful to handle it. And it is always most meaningful to handle

> And that's not something you do thanks to try/catch. You just handle the error where it's meaningful to handle it. And it is always most meaningful to handle it immediately, so what's the point of introducing a application-wide goto jump, amid Dijkstra's warnings that doing so is harmful when you're just going to catch right away anyway? > The happy path of "make a request" is that there is no network error. If there is a network error, you're still happy. It is not like you screwed up as a programmer. What is there to be unhappy about? The network error input to your function is very much expected and part of the "happy path" as much as any other input to your application. > if there is an unexpected network failure, let it crash Network failures are never unexpected. It would be exceptional to never experience a network failure. > How do you check which errors you want to handle and which one you want to propagate with just a string describing your error? Why would your errors be strings? When errors are just plain old values like any other it is true that you could resort to using strings to represent errors, but it would be quite unidiomatic to do so. Kind of like how you can overload exceptions to handle errors, but just because you can does not mean you should.