C#异常处理关键在于精准捕获与合理响应：只捕获能处理的异常，优先用TryParse等无异常API；捕获特定异常如FileNotFoundException或SqlException（1205）并针对性处理；禁用空catch和throw ex；资源清理首选using而非finally；finally中避免抛异常。
在C#中，异常处理的核心是try-catch-finally结构，但真正关键的不是“怎么写”，而是“什么时候捕获、捕获什么、怎么恢复或传递”。用错地方反而掩盖问题、破坏状态、拖慢性能。
只捕获你有能力处理的异常
不要为“看起来可能出错”的代码盲目套try-catch。比如调用int.Parse()时，如果输入不可控（如用户输入），更推荐用int.TryParse()——它不抛异常，返回bool，逻辑清晰又高效。只有当你需要区分不同错误类型（如格式错误 vs 范围溢出）、并能针对性响应时，才用try-catch。
- ✅ 捕获FileNotFoundException：可提示用户检查文件路径，或自动创建默认配置
- ✅ 捕获SqlException（特定错误号）：识别死锁（1205）并重试，而非泛捕Exception
- ❌ 泛捕Exception后只写个Console.WriteLine：掩盖根本问题，日志无上下文
catch块里别静默吞掉异常
空catch（catch { }）或只记录不处理，是常见反模式。即使暂时没对策，至少要重新抛出或包装：
- 用throw;原样重抛（保留原始堆栈）
- 用throw new CustomException("说明", ex);包装，添加业务上下文
- 避免throw ex;：会清空原始堆栈，调试困难
finally不是万能收尾，using才是资源清理首选
finally适合必须执行的清理逻辑（如手动释放非托管资源、还原全局状态）。但绝大多数情况，应优先用using语句——它编译后自动展开为try-finally，更简洁且不易出错：
- ✅ using (var file = File.OpenRead("log.txt")) { ... }
- ✅ using var conn = new SqlConnection(connStr);（C# 8+声明式using）
- ❌ 手动在finally里调用file.Close()：若构造函数已抛异常，file可能是null，需额外判空
不要在finally里抛异常
finally块中的异常会覆盖try/catch中已捕获的异常，导致原始错误丢失。如果清理操作本身可能失败（如关闭网络连接超时），应在finally内自行处理，或记录警告而不抛出：
- 用try { resource?.Dispose(); } catch (Exception cleanupEx) { Log.Warn("清理失败", cleanupEx); }
- 确保finally只做“尽力而为”的清理，不改变主流程错误语义
基本上就这些。异常处理不是语法练习，而是设计决策——明确边界、尊重上下文、留好线索。写得克制，比写得热闹更重要。
