java受检异常是编译期强制处理的exception子类（非runtimeexception），如ioexception、sqlexception；c#和kotlin取消该机制，依赖文档、统一包装、测试等工程实践保障健壮性。
Java 的受检异常（Checked Exception）是编译器强制要求处理的异常，比如 IOException、SQLException；而 C# 和 Kotlin 选择完全取消这一机制，所有异常在编译期都不检查——不是它们“不重视错误”，而是对错误性质、责任归属和工程实践做了不同判断。
核心分歧：异常该不该由编译器来“盯住”
Java 认为：某些失败（如文件不存在、网络超时）是外部环境导致的、可预期但不可控的，调用方必须知情并主动应对，所以编译器要拦住你，逼你写 try-catch 或声明 throws。
C# 和 Kotlin 认为：这种“强制签字”看似严谨，实际带来三类问题：
- 大量模板式代码：每个 IO 操作都得套一层 try，业务逻辑被淹没
- 错误被静默吞掉：为过编译，开发者常写
catch (Exception e) { }或只打日志，真正的问题反而被掩盖 - 异常信息上移失真：DAO 层抛
SQLException，Service 层被迫声明或捕获，但上层其实只关心“下单失败”，不关心底层是死锁还是连接池耗尽
它们怎么替代“强制处理”的作用
不靠编译器拦，不等于放任不管。C# 和 Kotlin 用其他方式保障健壮性：
- 文档与工具辅助：IDE 可基于方法签名、注释或 KDoc 提示“这个函数可能抛出什么”，但不阻断编译
-
统一异常包装：推荐在边界层（如 API 入口、Repository 调用处）把底层异常转为语义明确的业务异常（如
PaymentFailedException），再由顶层统一记录、告警或降级 - 测试驱动暴露：运行时异常本就对应“程序缺陷”，靠单元测试、集成测试和模糊测试提前触发，比强迫每个调用点写 catch 更有效
为什么 Java 难以放弃，而它们能甩开
Java 要向后兼容，已有海量代码依赖 throws IOException 这类契约；C# 从诞生起就没引入受检异常，Kotlin 设计之初就明确“不重复 Java 的历史选择”。更关键的是生态习惯：
- Java 工程师习惯了“看到红叉就补 try”，把编译检查当安全绳
- Kotlin 开发者更信任类型系统 + 不可空类型 + 密封类等机制来预防错误，异常只是兜底手段
- C# 用
async/await统一异步错误传播，让异常流更自然，也降低了对“强制声明”的依赖
这不是对错之争，而是权衡取舍
受检异常没让 Java 程序更少崩溃，运行时异常也没让 Kotlin 项目更难维护。真正起作用的，是团队是否建立清晰的异常分层规范：哪里该抛、哪里该转、哪里该记录、哪里该重试。语言只是提供工具，用不用得好，取决于人。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
