一、异常是避免不了的
异常是避免不了的。比如将一个八位数字字串转换为相应的日期。
初始的代码如下：
当接受的字串真是符合日期转换时，当然一切正常。
但是当字串不符合日期转换时，就发生异常了。
在这个类,能够避免预知的错误吗？能够利用Try...Catch...Finnaly吗？无论我怎么努力，我发现，无法避免，也不能使用Try...Catch。我就算告诉用户，你的输入错了，但我也无法输出合理的结果。能Return Nothing吗？不能！Nothing在DataTime里头就是0001年1月1日。为此，我只能什么都不处理，就让它异常好了。
二、异常真的不能避免吗
老天，我象是自打嘴巴了。
为了正常使用Dig8ToDateTime，我必须在用户界面上来检测输入是否合法。当我做到了这一步时，认为合法了，我发现，结果已经出来了，根本没有再使用Dig8ToDateTime这个类的必要。就是说，Dig8ToDateTime类毫无使用价值。
可我喜欢这个类，它在合法输入时带给我方便。现在，我变通一下，在输出结果前强制自检，不经自检，就不能使用Dig8ToDateTime.ToDateTime。
现在的代码如下：
用户(这里指编程者)在使用这个类，在不知其特殊用法的情况下，一般是这样写的：
在合法输入时，是正确的；不合法时，当然会发生异常：
于是会修改代码：
三、尽早预防异常
如果事前知道输入非法，那就可以即时回头，告知用户。下面，我加强了对数字合理性的判别。
四、尽可能减少异常抛出时间
Dig8ToDateTime类内还是不能避开异常的发生。闰年的二月，每月的31，不好判断。是能判断，可要做到的话，那这个类真没价值了。我只好用Try...Catch来应付。真遇到这种的非法输入时，肯定会发生异常，只不过是将异常控制在Try块内。这里还有没有改进的地方？既然避免不了异常的抛出，能不能缩短抛出的时间？以下想法只是估测，实际不知有没有用。
当运行环境遇到异常时，NET会寻找异常的类型，在运行库的异常数组里找，找到匹配的了，才抛出这个异常。我想的是能不能缩短它寻找的时间。看了帮助文档，DateTime.Parse()抛出异常的类型是FormatException，我就用它来代替Exception。实际上有没有效果呢，我真不知道。
这个类，我现在只能做成这样了。最后发现，无论如何，异常还是免不了的。并且，我还主动的生成新的异常New ApplicationException。
最后是这样，将Value改成属性。
测试代码：