接着我们来说你最开始提出的那个关于提高用户体验的问题。根据你的描述，我们认为急需要修改的是当程序遇到错误之后不应该是直接中断，而是给出提示，并使得用户可以重新输入。
在C#中错误和异常的解释是不一样的。异常是程序运行中发生的错误，异常处理是程序设计一部分。异常将导致不完善或者不需要的结果，因此在程序设计中需要处理异常。异常也可以是像"IndexOutOfBounds"(索引超过绑定)这样的错误，这个错误表示程序试图访问数组中不存在的元素；比如数组最大元素为100，当试图访问元素101时就将会发生这样的错误。但这些都是内建的异常，可以直接通过Exception基类处理，如果发生的异常不是内建的，那么就需要我们自己建一个异常处理类，当然这个类时继承自Exception基类。
从而看见，每种异常类型都是一个类。系统的异常被派生出了两大类，一种是系统内建的异常，这些都是系统定义的异常，被称为系统程序异常（System.SystemException）(系统程序异常查看附录)。一种是用户自己定义的异常，被称为应用程序异常（System.ApplicationException）。这两种异常按照具体的类型和特征的不同，又派生出了不同的子类。
小天：C#中的异常是怎么表现的呢？该不会又和MSSQL中那样给错误代码吧？
老田：异常被对象所表现而不是错误代码，比如说：exception e，他是对象引用e来表现出来的，而不是通过1、2等代码来表现出来的。异常的产生是通过throwing一个该异常的对象实现的，异常的捕获是通过catch该异常的对象。在自定义异常的命名时，我们应该采用可以读出是哪类异常: ArithmeticException, DivideByZeroException, etc。
需要注意的是：引发或处理异常时，将使用大量的系统资源和执行时间。引发异常只是为了处理确实异常的情况，而不是为了处理可预知的事件或流控制。例如，如果方法参数无效，而应用程序需要使用有效的参数调用方法，则可以引发异常。无效的方法参数意味着出现了异常情况。相反，用户偶尔会输入无效数据，这是可以预见的，因此如果用户输入无效，则不要引发异常。在这种情况下，请提供重试机制以便用户输入有效输入。
仅对特别条件引发异常，然后在应用于大多数应用程序的常规异常处理程序中捕捉异常，而不是在应用于特定异常的处理程序中捕捉异常。此方法的基础在于，大多数错误都可以通过验证以及与错误接近的错误处理代码进行处理；不需要引发和捕捉异常。通用目的异常处理程序捕捉的是在应用程序任意位置引发的、真正不可预期的异常。
此外，返回代码正常时不要引发异常；不要将返回代码转换为异常；也不要例行公事地捕捉异常、忽略异常，然后继续处理。
此文章为天轰穿原创作品，转载请注明作者及出处。
