JS wasn't designed to have a Go style of exceptions
not discussing the way the language handles side-effects (golang is built-in and javascript you need to wrap it in something like shown in this article), my personal experience is: it's just a matter of interface response pattern
i've being using it for node.js, typescript, flowtype, you name it... and it works pretty well, is just another pattern inside your codebase
in your example the error you pass on could be generated by .fetch() or by .json() and it's not going to be clear inside the main function
there is nothing preventing you to massage these responses... you can easily branch it in the catch:
in the same way you can inspect the error in the main function:
asyncfunctionmain(){let[err,res]=awaitapi.getRandomDog();if(err==="fetch-error"){// handle fetch error}if(err==="json-error"){// handle json error}// do something with `res`}
use your imagination, but be consistent! :) ... is rare when we need to have these granular error handling in the front-end... in my perspective, your back-end should be handling it (checking for missing params, not found user, credentials, etc)...
in an node.js/express world, your error middleware would be responsible for these branches and the client response/rejection could be only one!
i've being using it for node.js, typescript, flowtype, you name it... and it works pretty well, is just another pattern inside your codebase
Sure, I'm not against it, it's just that in a way you're limited to your perimeter of code, I wouldn't use it in a third party library. Most JS developers expect failure to be escalated to an exception so that if it's synchronous it can be caught and if it's async it can be handled. If suddenly you start returning two-valued arrays you're changing a silent contract. See how complicated it's going to be to change the way Go error handling is done. And Go is nowhere near as popular as JS.
It's not a bad idea inside an app though, as you say, if it's used consistently.
Thank you for your perspective!
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.
Hi Eduardo, nice example but there are a couple of things that make me unconvinced this is the best approach in JavaScript:
.fetch()
or by.json()
and it's not going to be clear inside themain
functionhow are you rhymes? thanks for your comment!
not discussing the way the language handles side-effects (golang is built-in and javascript you need to wrap it in something like shown in this article), my personal experience is: it's just a matter of interface response pattern
i've being using it for node.js, typescript, flowtype, you name it... and it works pretty well, is just another pattern inside your codebase
there is nothing preventing you to massage these responses... you can easily branch it in the
catch
:in the same way you can inspect the error in the
main
function:use your imagination, but be consistent! :) ... is rare when we need to have these granular error handling in the front-end... in my perspective, your back-end should be handling it (checking for missing params, not found user, credentials, etc)...
in an node.js/express world, your error middleware would be responsible for these branches and the client response/rejection could be only one!
many thanks 👋
well thanks :D hope the same for you
Sure, I'm not against it, it's just that in a way you're limited to your perimeter of code, I wouldn't use it in a third party library. Most JS developers expect failure to be escalated to an exception so that if it's synchronous it can be caught and if it's async it can be handled. If suddenly you start returning two-valued arrays you're changing a silent contract. See how complicated it's going to be to change the way Go error handling is done. And Go is nowhere near as popular as JS.
It's not a bad idea inside an app though, as you say, if it's used consistently.
Thank you for your perspective!