有关C#中in.Parse()和int.TryParse()的一点思考

毕设做的是一个.Net的横向项目。

由于数据库操作，和一些用户输入的判定，常要用字符串转整型变量的方法。

之前一直用int.Parse(string s)，方便省事。

后来发现，当s为null，或s格式不是严格的整型变量（如1.32）时，会抛异常（空指针或格式错误）。

所以，每次用int.Parse时会去捕获异常。

后来发现有一个方法，int.TryParse(string s, out int result)，当无法完成转换时，返回false，result置零，而且永远不会抛异常。

这个很好用有木有？

之后遇到int.Parse()的写法后，都会轻蔑地把这行代码展开成几行，先定义一个整型变量n，再用int.TryParse()尝试转换到n，根据返回值判断，若转换成功，则XXX...

虽然费了点事，但感觉整个系统鲁棒性都提高了有没有！

可还是忍不住要想，既然int.TryParse这么好用，那为什么还要int.Parse呢？它的存在究竟有什么意义？兼容旧版写法？

在网上查了很久也没查到原因。几乎所有的帖子、博文都会分析int.Parse和int.TryParse的区别，但谁也没说出到底什么情况该用哪个方法。

今天同样在查，偶然看到一个提问。有关 int.parse和int.tryparse的困惑。采纳的最佳答案没太大意义。后边有个ID的回答是这样的：

“我个人的习惯是：有可能出现异常时（比如尝试parse一个用户输入的string），用TryParse。当不可能出现异常（或者说出现异常属于事故级），比如我要parse一个确保是int的string时，直接parse不捕获异常。确保是int的string大概是这样的情况: 比如我从数据库中读取一个string，这个string是我之前的代码写入到数据库的，已经检查过了是int。那么这种情况下直接parse。因为如果这种情况下还抛异常，说明是之前的写入代码检查逻辑有问题，应该去修改那里的代码而不是把这里改成tryparse。”

说的好有道理！正是我想要的答案！

当一个地方是从数据库中取出的值，虽然在程序中用字符串存储，但在数据库中确实是整型字段。这时，其实是没有必要用int.TryParse的。因为先前在存入数据库时就验证过了。假使这里抛了异常，也不是这个地方出了错，而应该去输入判定的地方检验。也就是说，这里的异常是不允许抛的，一旦抛出，就说明这个BUG是程序员的责任——先前的输入判定没有做好。

在用户可能直接造成异常的情况下，譬如读取用户输入，那当然要用int.TryParse判断一下咯。

这种出错处理的思想，正是我在横向项目中需要更加深入去体会的。