在Ktor服务端全局处理HTTP异常是否是合理的通用开发实践？

这种全局集中处理HTTP异常的方式是完全主流的行业通用开发实践，完全可以放心使用。

目前几乎所有成熟的服务端框架都原生提供了类似的全局异常处理能力，比如Spring生态的@ControllerAdvice、Go Gin的错误处理中间件、Node.js Express的错误捕获中间件，包括你在用的Ktor的StatusPages组件，本质都是这套逻辑，是经过大量项目验证的最佳实践，核心优势非常明显：

• 业务代码更简洁：你写的那两个扩展方法就是典型的正确用法，业务逻辑里只需要处理正常流程，遇到不符合预期的场景直接抛出对应异常即可，不需要在每个接口里重复编码构造错误响应，大幅减少冗余代码。
• 错误响应格式统一：所有异常都经过统一逻辑处理返回，能保证整个服务的所有错误返回的报文结构完全一致，不管是参数错误、资源不存在还是业务冲突，前端都可以用统一的逻辑处理错误提示，降低前后端对接成本。
• 便于统一做额外逻辑：后续如果要加错误日志上报、异常告警之类的能力，只需要在全局异常处理的逻辑里加一次就行，不用挨个修改业务接口。

你遇到的没有内置409 Conflict异常的问题属于正常情况：框架只会内置最通用的几个HTTP异常类，409这类偏向特定业务场景的状态码，本来就需要开发者自定义，实现成本很低，完全符合这套设计的预期。你可以参考内置异常的实现自定义ConflictException，再在StatusPages中注册对应的处理规则即可。

你原有工具方法的实现是合理的：

fun Parameters.getString(name: String) =
    get(name) ?: throw BadRequestException("Missing or malformed $name")

fun <T> T?.ensureExist(name: String) =
    this ?: throw NotFoundException("No $name found")

自定义409异常和配套配置的参考示例：

// 自定义409冲突异常类
class ConflictException(message: String) : RuntimeException(message)

// 按需新增配套扩展方法，比如校验资源是否冲突
fun <T> T?.ensureNoConflict(conflictMessage: String) {
    if (this != null) throw ConflictException(conflictMessage)
}

// StatusPages组件中新增409异常的处理规则
install(StatusPages) {
    // 原有其他异常的处理逻辑保留即可
    exception<ConflictException> { call, e ->
        call.respond(HttpStatusCode.Conflict, ErrorDTO(code = 409, message = e.message.orEmpty()))
    }
}

你甚至可以根据业务需求给自定义异常增加额外的字段，比如业务错误码、错误详情列表等，灵活适配项目的错误规范。

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