将整个函数包裹在try...catch块中是否属于不良开发实践？

我习惯把完整的接口处理函数整个包裹在try...catch块里，如果部署前没发现bug，catch部分会打印错误栈并给我发告警邮件。想问问这种做法算不算不良开发实践？下面是我的接口示例：

app.get('/api/get-furniture', async (req, res) => {
    try {
        const query = 
        `SELECT Clase.nombre AS clase, Grupo.nombre AS grupo, Subgrupo.nombre AS subgrupo
        FROM Subgrupo
        JOIN Grupo ON Subgrupo.grupo_id = Grupo.id
        JOIN Clase ON Grupo.clase_id = Clase.id;`;
        // cast Class Name to "Clase", Group Name to "Grupo", and Subgroup Name to "Subgrupo"
        // start from Subgrupo table
        // join Grupo table on Subgrupo's grupo_id
        // join Clase table on Grupo's clase_id

        const result = await dbRequest(query); // get furniture data from database

        const data = {};
        result.forEach((row) => {
            if (!data[row.clase]) data[row.clase] = {}; // if class doesn't exist in data, create it
            if (!data[row.clase][row.grupo]) data[row.clase][row.grupo] = []; // if group doesn't exist in class, create it
            data[row.clase][row.grupo].push(row.subgrupo); // add subgroup to group
        });

        res.json(data); // send furniture data
    }
    catch (error) {
        errorEmail('Endpoint get-furniture', error);
        res.status(500).send('Internal server error');
    }
});

这种做法不算绝对的不良实践，但存在明显的优化空间，得结合场景调整：

优点 #

• 能兜底所有未预见的错误，避免因单个逻辑漏洞导致接口完全崩溃，同时通过告警邮件及时感知问题，方便快速排查。
• 实现成本低，不用逐个梳理可能出错的点，适合快速开发或对稳定性要求较高的基础接口。

存在的问题 #

• 错误粒度太粗：所有错误都被统一返回500内部错误，无法区分错误类型。比如数据库连接失败、SQL语法错误、数据处理逻辑bug，用户收到的都是同样的提示，既不利于前端做针对性处理，也会增加你排查问题的时间成本。
• 不符合HTTP规范：有些错误本应返回特定状态码，比如如果后续接口加了参数校验，参数缺失应该返回400 Bad Request，而不是混在500里，统一catch会模糊这些语义。
• 隐藏可预期错误：本该提前处理的业务逻辑错误（比如数据为空的情况）也会被当成未知错误触发告警，导致告警噪音增多。

优化建议 #

• 拆分捕获粒度：针对关键风险点（比如数据库查询）单独加try...catch，针对性处理。比如数据库查询出错时，判断是连接问题还是SQL语法问题，返回不同状态码，告警里也标注清楚错误类型。
• 用全局错误中间件兜底：像Express这类框架支持全局错误处理中间件，把全局兜底逻辑放在中间件里，接口内只处理特定业务错误，既保证所有错误都能被捕获，又能让接口逻辑更清晰。
• 错误分类处理：在catch里根据error的类型、错误码做区分，比如业务逻辑错误返回4xx状态码并给用户明确提示，系统级错误返回500并触发告警。

内容的提问来源于stack exchange，提问作者Marvil