NodeJS中的异步等待（尝试/捕获）

Question

I'm working on a NodeJS API and I was wondering which of the following 2 examples in the ROUTES FILE is best practice. As you can see in one I'm adding the try/catch and in the other I'm not. Notice in the Service.js file I added the try/catch as well. Do I need it in one place only or using it in both places is better?

ROUTES FILE

 const todo = router => {
      /* EXAMPLPE 1 */
      router.get('/tasks', isAuth, async (req, res, next) => {
        const results = await TodoService.getTasks();
        return res.status(201).json(results);
      });

      /* EXAMPLPE 2 */
      router.get('/tasks', isAuth, async (req, res, next) => {
        try {
           const results = await TodoService.getTasks();
           return res.status(201).json(results);
         } catch (e) {
             return next(e);
         }
      };

SERVICE.JS

class TodoService {
  static async getTasks() {
    try {
      const tasks = await TaskModel.find();
      return {
        message: 'Fetched posts successfully.',
        tasks: tasks,
        status: 200
      };
    } catch (err) {
      if (!err.statusCode) {
        err.statusCode = 500;
      }
      return err;
    }
  }
}

Answer 1

In the now edited version of your question, getTasks() can NEVER reject its promise (since you catch any possible rejections and turn them into a resolved promise). Therefore, the caller in your example 2 contains a completely pointless try/catch that is basically dead code that can never be used. While it looks like it might be safer code, it's basically wasted code.

Make it absolutely clear in the doc/contract for the function whether it can or cannot reject. If it can't, then there's no reason for the caller to attempt to handle a rejection as that is just pointless code.

Personally, I think it's probably more flexible to let errors flow back through a rejected promise since that can be used in more places and combined with other operations more easily. But, if the ONLY purpose is as a single part of a request handler, then it may save code to centralize the reject catching and turn it into a resolved object that you return like you are now. Less flexible for different types of callers, but perhaps simpler code to centralize the reject catching if the purpose of calling the function is always narrow.

There is no right/wrong answer. It's mostly a matter of what you're most trying to optimize for (flexible caller use vs. centralized error catching) and your personal style preference.

Answer 2

Unfortunately, the OP edited their question to make it different AFTER I wrote this answer. This answer was written to the original version of the question.

Either works fine and it's really a matter of opinion which one will like.

In the first, you make sure that the method call can NEVER return a rejected promise, therefore you don't have to catch rejections in the caller.

In the second, you can have a rejected promise returned so you have to catch rejections in the caller.

Personally, it looks like a coding error whenever I see an await that has no code that ever catches a rejection so you'd have to well document that the method NEVER rejects. I personally think it's more flexible if errors reject and the caller can then decide what to do. That allows the method to be used by a wider variety of callers, but then does require the caller to catch rejections.

On the other hand, if ALL possible uses of the function are in request handlers where all you want to do is have a status returned with no rejections so that status can be sent back as the response, then you're probably saving code by catching errors centrally in the function rather than in every caller.

Like I said, it's mostly a matter of coding style preference. You just have to make sure that any possible promise rejection is handled somewhere so you always send an appropriate response to the incoming request.

Answer 3

The concepts here are valid but this is pseudo code, I have not run it. Additionaly any terms in 'quotes' are not correct terminology

Something important to remember when developing a hierarchy with try catch is that errors are always thrown up the three. Therefore you should always ensure you have a try catch at the highest level in order to handle errors.

In your case where you might throw an error in a service and handle it in a route, your service would be best left as a 'pure function' to catch higher up. I find this will subconsciously allow you to avoid Circular dependencies as well. A case where you might use a try/catch on both 'levels' could be if you want to throw custom errors.

An example of that is:

// Router
Router.get('/tasks', async (req, res) => {
    try { 
        return await TodoService.getTasksById(taskId);
    } catch (err) {
        return errorResponseUtility(err.status, err.message);
    }
}

// Service
const getTasksById = async id => {
    try {
        return await DB()
            .connect('tasks')
            .select('*')
            .where({ id });
    } catch (err) {
        if(err instanceOf NotFoundError) throw err;
    }
}

// Error Defs
const NotFoundError = {
    status: 404,
    message: 'Resource could not be found'
}

This way if you don't have anything you can error but in a correct way VS a random 502

Other: Destructure your req.params:

const { id: taskId } = req.params; // This renames id to taskId

Alternatively, don't destructure it, just parse it straight through since it is only used once.

Answer 4

So the answer depends on code style. Javascript has a lot of ways to structure code. Your first option is closer to a functional style using the arrow function, the second is using the class setup introduced in ES2015.

However, only the first actually creates the router. So you still need code to map your static methods in the TodoService to URLs.

Developers coming from Java will find your class based code easier to follow. People with experience doing small services in express may find the first example easier to follow.

My personal preference as a developer is to make it as easy as possible to map API calls in logs to code. One of the things I like about express is how easy this is with nested routers and middleware.

So to me, your first is close. I just wouldn't have any anonymous functions. Instead those functions should be in an external file, maybe routes.js , and are setup so that you can unit test them easily.

eg

routes.js

function makeTaskRoute = function(TodoService) {
 return async getTasks(req, res, next) => {
    const results = await TodoService.getTasks();
    return res.status(201).json(results);
 }
}

module.exports = {
  makeTaskRoute
}

Then in index.js

const TodoService = require('todo/service/TodoService.js');
const getTasks = require('./routes/routes.js').makeTaskRoute(TodoService);
const router = express.Router()

router.get('/tasks', getTasks);

This is a more functional style but also allows dependency injection and easy testing.

There's even more to do to make this cleaner, and a lot is preference. But I've found this (plus using declared types in typescript and cleanly separating out data structures and mutations) to be clean, easy to read, and easy to maintain and improve.