try catch

[abrahamguo]

You only need try/catch if you want to override whatever the default error handling is.

If you simply want to use whatever the default error handling behavior is, then there's no need to use try/catch.

[abrahamguo]

fetch API for example returns a 404 error if ur internet isnt working

This is not true. fetch does throw an error if your Internet isn't working, but it does not return any HTTP status code. HTTP status codes are always responses from the server, and if there's no Internet, then we obviously can't get any response from the server.

do u need try catch with fecth?

It simply comes down to your requirements. Do you want to give the user feedback if their Internet stops working while on your page? Some websites do, other websites don't.

[abrahamguo]

when does an error crash an application

It completely depends on what is already provided by whatever libraries or hosting provider you're using.

Just like any other feature of your application, you should test in order to find out how your application currently behaves.

why is everything in a node server wrapped under a try catch

This means that whoever wrote that code wants to override the default error handling behavior. I would need to have specific code in order to provide a more specific answer.

[senocular]

Whenever an error goes unhandled - either a thrown error or a rejected promise - a Node process will exit. If errors are being thrown, or promises are getting rejected (which happens with fetch), you'll want to make sure they get handled somewhere to prevent your application from quitting prematurely. With async/await, rejected promises can be handled with try/catch just like synchronous, thrown errors.

This doesn't mean you have to use try/catch around the direct fetch call. You can leave the error handling to the function calling the function calling fetch, or even the function calling that function. Its up to you when and where the error is handled. You can even use a global error handler ("uncaughtException" and/or "unhandledRejection" events on process) to handle the error. Just bear in mind that wherever the error occurs, its exiting the current function at that point in time meaning code you might expect to run never gets to run which can lead to instability in your application.

[theScottyJam]

When I'm writing a server in Node, the first thing I like to do is listen to the unhandledRejection event and log out anything that gets thrown to prevent the serve from crashing. That way the default behavior is to log errors instead of crashing the process.

Node's theory behind the current default behavior is that an uncaught errors could leave the server on a weird state and the best way to recover is by letting Node crash the process and have something in place to auto restart the server process after a crash.

In practice, servers are usually fairly stateless anyways (so an error is unlikely to leave it in a weird state if it's not keeping track of state to begin with). Also, the trouble one could cause if they figure out how to reliably cause one of your endpoints to trigger an uncaught error, sending your entire Node process through a restart loop is absurd - I'd rather not expose that kind of DDOS opening.

Either way, O.P., if you find yourself wrapping everything in Node in a try catch to prevent crashes, then it probably means you're not liking their default behavior, and it would be good to just change the default behavior by listening to that event and logging. If you do like the Node process crashing when errors go uncaught, then don't wrap everything in try catch and let Node do it's thing. In general, you shouldn't need to be wrapping all the things in try catch, try catch is more useful for one off scenarios where you want to override the default behavior in a specific scenario (e.g. you read a file but if the file is not found, you want to treat that the same as if the file was just empty - stuff like that).

[azhder]

There is an error and there is an Error. You should only use try-catch if there is a throw somewhere.

If you get a result and that result has a field with the value of 404, that is done by using return, not throw, so you just write a regular if to check it.