独立开发者为何需重视C#的异常处理与封装？

关于封装：不是防别人，是防“未来的自己” #

你说全设public程序也能跑，这点没错——但那只限于当下。独立开发最容易踩的坑，就是“自己忘了自己写的代码”：

• 避免无意识破坏内部状态：比如你写了个ShoppingCart类，把Items字段设为public，今天图方便直接cart.Items.RemoveAt(0)；过三个月给ShoppingCart加了“删除商品需同步更新总价”的逻辑，之前直接操作Items的代码不会触发这个逻辑，导致总价计算错误，你得花半天找哪段代码绕开了规则。如果把Items设为private，只提供RemoveItem方法，所有删除操作都会走统一逻辑，根本不会出这种问题。
• 重构成本骤降：假设你一开始用List<Order>存储订单，后来发现需要快速查找，想换成Dictionary<int, Order>。如果所有访问都是通过GetOrderById这类公共方法，你只需要改内部实现，外部调用代码完全不用动；要是List<Order>是public，你得搜遍整个项目，把所有直接操作这个列表的代码都改一遍，工作量翻几倍。
• 降低大脑负担：你不用记每个字段的“使用规则”，只需要记公共方法的作用。比如User.ResetPassword()比直接改User.Password更清晰——你知道这个方法会生成临时密码、发邮件、更新修改时间，而直接改字段可能漏做这些步骤。

关于异常处理：手动抛异常是给“未来的自己”留的调试线索 #

你觉得自己不需要详细错误信息？等你隔三个月调试自己写的程序，就会明白这有多重要：

• 快速定位bug根源：比如你写了个CalculateTax(decimal amount)方法，传入负数时如果不抛异常，可能返回0或者负数的税，你得一步步查哪里传入了负数；如果手动抛ArgumentOutOfRangeException("金额不能为负数")，调试时看到异常信息，瞬间就知道是参数问题，直接去查调用这个方法的地方。
• 阻止隐性错误扩散：假设你允许用户输入非数字的手机号，不抛异常的话，程序可能把这个字符串存进数据库，后续发送短信、验证身份时全出问题，你还得追溯到源头；提前抛FormatException("手机号格式错误")，在输入环节就把问题解决，不会让错误流到后面。
• 代码自带文档：手动抛异常相当于给代码加了“强制执行的注释”。比如public void Withdraw(decimal amount)里抛InvalidOperationException("余额不足")，不管过多久你看这段代码，都知道这个方法的限制，比写个容易过期的注释靠谱多了。
• 可控的失败比静默错误好：比如读取配置文件失败，手动抛FileNotFoundException("配置文件不存在")，你马上知道是文件的问题；如果程序默默用默认配置，后续功能全错，你可能以为是业务逻辑bug，查半天方向都错了。

最后说句实在的 #

小项目初期全public、不抛异常确实能省时间，但随着项目变大（哪怕只是你自己加功能），这些“偷懒”的地方会变成一个个隐形炸弹。现在花10分钟给字段加private、给参数加异常判断，未来能帮你省几小时的调试时间——独立开发者的时间本来就宝贵，没必要浪费在给自己挖坑上。

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