Properly handling errors with Node/Express

Question

Which is the proper way to return errors with your server in general (node/express) and reject a promise?

---

A) Like this: res.json({status: 1, message: 'Test missing phone.', error: 'phone'})

And then pull the error 'code' out of error and the message out of messsage on your front end, resulting in a fulfilled promise that has an error and message in it.

---

B) Like this;

res.status(500)
res.json({message: 'Test missing phone.'})

And then just pull message out and call .reject with the message. Or res.error or something.

---

Do either of these cause a 'rejected' promise or 'error' callback that would make frontend stuff easier?

Should I be causing promise/callback rejection when I get an error, or just send a fulfilled promise with an error in the object like A?

Which of these is the 'correct' way to return an error from your server to your front end?

Currently I use method A, but it seems pretty dumb because I have to handle the error twice, backend (to actually send the custom error) and frontend (to check if the fulfilled promise has an error object, and then display a popup). Method B would eliminate the 'checking if the fulfilled promise has an error object' part, since a rejected promise is an error by nature.

EDIT: I'm using React Native as frontend.

EDIT2: If you res.status(500).json({test: 'Test missing phone.'}) on your backend you can console.log(error.response.data) on the frontend to make "B" a viable option.

Answer 1

TL;DR Use your "B" method

Depends on what you're using on the front-end. If it's Angular and you're using the $http object for example, the promise will get rejected if there's an error status (for example, a 400 status code) according to the docs.

So to allow the front end to "know" when there's an error automatically (instead of having to do some extra checking to see if the body contains an error message), you should probably go with the res.status() approach on the back-end. HTTP status codes are the model that you should be using for your front-end to know what's going on in the server, and most front-end HTTP libraries are built with this model in mind.

You can send additional info in the body of your response too if you want. You can have custom app code on the front-end that handles more granular error cases. For example, a status of 401 would tell the client that they're unauthorized to do some action on the server, and a body with a code member might further define exactly what the issue was, along with some human-readable description (which you already have as message in your example).

Answer 2

Adding in the res.status(500) is proper in terms of best practices. If you say that there are 'errors with your server' you should definitely label the response as such - i.e. response code 500 which indicates exactly that.

While you know what kind of responses to expect, if this were a project you were developing with others or an API to be shared to the public, it would seem counterintuitive to not get a 500. Sending that 500 will make handling the error more straightforward whether using promises or vanilla ajax.

That said, no reason you can't also include the full JSON object that you mentioned from part A (i.e. {status: 1, message: 'Test missing phone.', error: 'phone'}) to provide more info to your front end.