Spring控制器内用try/catch是否为不良实践？该遵循何种标准？

控制器里直接写try/catch确实不属于Spring生态下的标准实践，更推荐你沿用GET接口的思路——自定义业务异常+统一异常处理器的方式，原因和具体做法如下：

为什么控制器里的try/catch不好？ #

• 代码冗余且难维护：每个接口都重复写try/catch，后续要修改错误返回格式或新增异常场景时，得逐个修改控制器，效率极低。
• 异常信息模糊：你代码里catch (Exception e)会捕获所有异常，不管是参数格式错误、玩家不存在还是数据库约束冲突，都返回笼统的"Could not delete a player"和500状态码，前端没法区分错误类型，后端排查问题也找不到具体原因。
• 职责边界混乱：控制器的核心职责是接收请求、调用业务逻辑、返回响应，异常处理属于横切关注点，应该统一抽离，而不是散落在每个接口方法里。

标准实践流程（结合你的场景） #

1. 定义细分的自定义业务异常 #

针对不同错误场景创建具体的异常类，明确业务层面的错误类型：

public class PlayerNotFoundException extends RuntimeException {
    public PlayerNotFoundException(String message) {
        super(message);
    }
}

public class DeletePlayerFailedException extends RuntimeException {
    public DeletePlayerFailedException(String message) {
        super(message);
    }
}

2. Service层抛出具体异常 #

Service层负责业务逻辑，遇到不符合预期的场景时直接抛出对应自定义异常；对于框架抛出的底层异常（比如数据库约束异常），转成业务异常抛出，不要默默处理：

@Override
public void deletePlayer(Long id) {
    // 先判断玩家是否存在，不存在则抛业务异常
    if (!playerRepository.existsById(id)) {
        throw new PlayerNotFoundException("Player with id: " + id + " does not exist");
    }
    try {
        playerRepository.deleteById(id);
    } catch (DataIntegrityViolationException e) {
        // 把数据库约束异常转成业务异常
        throw new DeletePlayerFailedException("Cannot delete player: related records exist");
    }
}

注意：Spring Data JPA的deleteById方法如果找不到对应ID的记录，不会主动抛出异常，所以需要手动判断存在性。

3. 统一处理异常（局部或全局） #

沿用你GET接口的@ExceptionHandler思路，推荐用@ControllerAdvice做全局异常处理（适合多控制器共享）：

@ControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(PlayerNotFoundException.class)
    public ResponseEntity<String> handlePlayerNotFound(PlayerNotFoundException e) {
        return ResponseEntity.status(HttpStatus.NOT_FOUND).body(e.getMessage());
    }

    @ExceptionHandler(DeletePlayerFailedException.class)
    public ResponseEntity<String> handleDeleteFailed(DeletePlayerFailedException e) {
        return ResponseEntity.status(HttpStatus.CONFLICT).body(e.getMessage());
    }

    // 处理参数格式错误等通用异常
    @ExceptionHandler(NumberFormatException.class)
    public ResponseEntity<String> handleInvalidIdFormat(NumberFormatException e) {
        return ResponseEntity.status(HttpStatus.BAD_REQUEST).body("Invalid player ID format");
    }
}

如果只需要在当前控制器生效，也可以把@ExceptionHandler方法直接写在PlayerController里。

4. 简化控制器代码 #

修改后的delete接口无需try/catch，逻辑更简洁：

@DeleteMapping("/api/players/{id}")
ResponseEntity<String> deletePlayer(@PathVariable String id) {
    playerInterface.deletePlayer(Long.valueOf(id));
    return ResponseEntity.ok().body(String.format("Player with id: %s has been deleted", id));
}

关于Service层是否要捕获异常 #

Service层不应该捕获业务异常，而是要把异常抛出去。Service的职责是处理业务逻辑，异常是业务逻辑的一部分（比如"玩家不存在"是业务上的错误场景），让上层的统一异常处理器来处理，才能保证业务逻辑清晰，同时让异常处理集中可控。

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