Please forgive my ignorance but I'd really appreciate advice on the nature of the exceptions you're aiming to catch.
I see plenty of exceptions thrown by my own rubbish code during Javascript and PHP development, but these get sorted out during testing. I'd have thought that Production systems should surely see only network exceptions.
However, I mostly find myself using Fetch() and here network error are returned as an HTTP error status. Accordingly, I wouldn't expect them to trigger a catch.
As a matter of fact, I do currently use the pure promise style rather than await and do attach a catch block at the end of my .then stacks. But I've yet to see one triggered!
I think I must be missing somthing and I'd really like to know what it is!
I write code, front-end and back-end, and like deploying it on AWS. Software Developer for 20 years, and still love it. Amateur Powerlifter & Parkourist.
Caveat: Most of this is with node-fetch in Node.js, not fetch in the browser. But similar things happen.
The first ones are like you said, during testing, like your parameters are messed up. You requested a person ID, but the person ID is null, so the entire function breaks.
The second ones are when you get back stuff that isn't JSON, so when response.json() runs, it breaks. At large companies this could be your firewall or WAF, or when the back-end freaks out and instead of sending JSON back, the nginx server sends an HTML error page.
The third ones are a mixup of the above. Sometimes you'll get a statusCode of 401 for example, but the response is in JSON giving you more details about it. However, your code gives back a bogus JSON response and that triggers other null pointers because they were expecting a good JSON response, not an error one.
The fourth is when all happy path is good, and the API changes something about the JSON; your fetch code works, but the code around it fails. You think it's the fetch' fault, but it's actually the API changing the schema. If you have schema validation (like ajv or something), this can help.
Occasionally I'll learn of a new one where my certs are wrong deployed to AWS and the fetch will throw "because https weirdness", or occasionally I'll get a 500 from the upstream and didn't handle the response correctly (text vs. JSON vs. html).
Those last ones are what kill me. The ones above I can convert all to pure functions, including data parsing where they never throw, just return a Result.Error vs. a Result.Ok. I like it better how in Elm has solidified it into 5 return values, and you can code to that interface, and you know exactly where the prolbem lies: with you or the back-end.
It could just be you've worked with stable back-end systems, mine are either green field and changing, or have a lot of technical debt. Locally, things can be different because of strict proxy.
Thanks Jesse, I really appreciate that. As you've detected, I'm working generally in stable (and low stress) areas but I've certainly sen the JSON problem often enough now and will concentrate on handling that one in future. Thanks again for your time and consideration, MJ
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.
Please forgive my ignorance but I'd really appreciate advice on the nature of the exceptions you're aiming to catch.
I see plenty of exceptions thrown by my own rubbish code during Javascript and PHP development, but these get sorted out during testing. I'd have thought that Production systems should surely see only network exceptions.
However, I mostly find myself using Fetch() and here network error are returned as an HTTP error status. Accordingly, I wouldn't expect them to trigger a catch.
As a matter of fact, I do currently use the pure promise style rather than await and do attach a catch block at the end of my .then stacks. But I've yet to see one triggered!
I think I must be missing somthing and I'd really like to know what it is!
Caveat: Most of this is with node-fetch in Node.js, not fetch in the browser. But similar things happen.
The first ones are like you said, during testing, like your parameters are messed up. You requested a person ID, but the person ID is null, so the entire function breaks.
The second ones are when you get back stuff that isn't JSON, so when
response.json()runs, it breaks. At large companies this could be your firewall or WAF, or when the back-end freaks out and instead of sending JSON back, the nginx server sends an HTML error page.The third ones are a mixup of the above. Sometimes you'll get a statusCode of 401 for example, but the response is in JSON giving you more details about it. However, your code gives back a bogus JSON response and that triggers other null pointers because they were expecting a good JSON response, not an error one.
The fourth is when all happy path is good, and the API changes something about the JSON; your fetch code works, but the code around it fails. You think it's the fetch' fault, but it's actually the API changing the schema. If you have schema validation (like
ajvor something), this can help.Occasionally I'll learn of a new one where my certs are wrong deployed to AWS and the fetch will throw "because https weirdness", or occasionally I'll get a 500 from the upstream and didn't handle the response correctly (text vs. JSON vs. html).
Those last ones are what kill me. The ones above I can convert all to pure functions, including data parsing where they never throw, just return a
Result.Errorvs. aResult.Ok. I like it better how in Elm has solidified it into 5 return values, and you can code to that interface, and you know exactly where the prolbem lies: with you or the back-end.It could just be you've worked with stable back-end systems, mine are either green field and changing, or have a lot of technical debt. Locally, things can be different because of strict proxy.
Thanks Jesse, I really appreciate that. As you've detected, I'm working generally in stable (and low stress) areas but I've certainly sen the JSON problem often enough now and will concentrate on handling that one in future. Thanks again for your time and consideration, MJ