对错误和异常的区别的理解

异常是原子性，错误是可以没有，可以不rallback
在不可预短的，具有原子性操作的，可用try
否则，我删文件删了一半，就出现异常。。。
那我这个文件会rallback，还可以打开
错误的处理方式有很多种，
１。中间值，继续执行
２。不执行，提示错误
3.部分执行，给出每一步的提示

当然还有很多
异常产生错误
异常的处理只有一种:
1.要么全部执行成功，要么全部不执行
所以，.net Framework不般都是检测到
try
{
input==null
}
因为我全部都不执行
并且.net Framework的用户是程序程序员，调用我，都应该是可信的数据，否则都是错不正常的

异常是意思是，不正常，
在正常的的情况下，发生了不可预知的事情，视为异常
异常的前置条件是正常
错误的假设有两种，
一种为正常
一种为不正常，即错误

错误是分类到错误类，正常的分类正常类

异常的前置条件是正常与错误
错误的前置条件是正常与错误

例如用户的输入，有可能正确，有可能错误，就应该用错误，给预相关处理

异常与错误的前置条件不一样
但后置条件一般一样，现在的多大程序是这样

不可信数据，一般使用错误
可信数据，一般使用异常

界面上的数据，一般先都要validat前采用错误，validate后采用异常

microsoft说，我们的程序员已经成长起来了，我们信任我们的程序员，.netFramework采用的异常

 异常是给管理员看，错误给用户看

 

异常的前置条件是正常，是可信数据，所以提示的资料相当详细，堆栈的信息，具体哪一步等等

而错误针对的是不信可用户，所以给客户比较“您”，信息也经过包装，不够具体

 

总结：

错误和异常的前置不一样。

处理方式有可能也不一样。

原子性也可能不一样。

信息的内容可能也一样。

关键是可信与不用信用户的问题

========================================

 

 这个问题说起来可大了，讲一两个小时也不够。  
  简单说说我的理解：  
  异常和错误基本上是一样的，区别在于错误是可以预见到并且知道如何处理的情况而异常是指出错了但不知如何去处理的情况。或者说：如果知道出错后该怎么处理就可以直接处理该错误，否则就将其作为一个异常抛出（在知道如何处理地方捕捉该异常然后进行处理）。  
  c++异常相对返回错误码的优点：  
  1.   可以强制对该错误进行处理，如果不处理则程序coredump  
  2.   可以从内层嵌套中直接跳出  
  3.   代码更简洁  
  4。会进行堆栈解退  
  缺点：  
  1。增加一定的开销  
  2。破坏的程序的结构性。  
  3。要正确使用异常机制不太容易，有很多需要小心的地方  
   
  据说对于c++异常的争论很多，我想可能就是因为以上缺点吧。（不过我看的书都是鼓吹c++的，所以没能看到反面的意见）。

 

========================

错误

不管是哪一种服务操作，在任意时刻都可能遭遇一些不可预期的错误。问题在于如何将错误报告给客户端。异常与异常处理机制是与特定的技术紧密结合的，不能够跨越服务边界。此外，错误处理通常都属于本地的实现细节，不会影响到客户端。这样设计的原因在于客户端不需要关心错误的细节（以及发生错误的事实），但最主要的还是因为在设计良好的应用程序中，服务是被封装的，因此客户端无法知道有关错误的信息。设计良好的服务应尽可能是自治的，不能依赖于客户端去处理或恢复错误。任何非空的错误通知都应该是客户端与服务之间契约交互的一部份。本章介绍了服务与客户端如何处理这些声明的错误，以及如何扩展与改善这样一种基础的实现机制。

错误与异常

在传统的.NET编程中，任何未经处理的异常都会立刻终止抛出异常的进程。但WCF却与之大相径庭。如果代表某个客户端的服务调用导致异常，并不会结束宿主进程，其他客户端仍然可以访问该服务，托管在相同进程中的其他服务也不会受到影响。因此，当一个未经处理的异常离开服务的范围时，分发器会捕获它，并将它序列化到返回消息中传递给客户端。当返回消息到达代理时，代理会在客户端抛出一个异常。

当客户端试图调用服务时，实际上可能会遭遇三种错误类型。第一种错误类型为通信错误，例如网络故障、地址错误、宿主进程没有运行等。客户端的通信错误表现为CommunicationException异常。

客户端可能遇到的第二种错误类型与代理和通道的状态有关，例如试图访问已经关闭的代理，就会导致ObjectDisposedException异常。或者契约与绑定的安全保护级别不相匹配，也会出现错误。

第三种错误类型源于服务调用。这种错误既可能是服务抛出的异常，也可能是服务在调用其他对象或资源时，通过内部调用抛出的异常。这些错误正是本章所要讲述的主题。

出于封装与解耦的目的，在默认情况下，所有服务端抛出的异常总是以FaultException类型到达客户端：

public class FaultException : CommunicationException

{...}

如果要解耦客户端与服务，就应该对所有的服务异常一视同仁。客户端知道服务端发生的内容越少，则两者之间关系的解耦才越彻底。

异常与实例管理

当服务实例出现异常时，WCF并不会关闭宿主进程，但错误可能会影响服务实例，同时还会影响到客户端继续使用代理（事实上是通道）访问服务的能力。准确的说，异常对于客户端与服务实例的影响与服务的实例模式有关。

单调服务与异常

如果调用引发异常，那么紧跟在异常之后，服务实例会被释放，代理将在客户端抛出FaultException异常。在默认情况下，所有服务抛出的异常（包括FaultException的派生类）会使得通道发生错误。即使客户端捕获了异常，它也不能发出随后的调用，因为它们会引发一个CommunicationObjectFaultedException异常。此时，客户端只能关闭代理。

会话服务与异常

无论使用何种WCF会话绑定，在默认情况下，所有异常（包括FaultException的派生类）都会终止会话。WCF将会释放实例，而客户端则获得一个FaultException异常。即使客户端捕获了该异常，也不能继续使用代理，因为随后的调用会引发一个CommunicationObjectFaultedException异常。客户端唯一可以安全执行的就是关闭代理，因为一旦参与会话的服务实例遇到了错误，会话就不能再使用了。

单例服务与异常

当我们调用单例服务时，如果遇到异常，单例实例并不会终止，而是继续运行。在默认情况下，所有异常（包括FaultException的派生类）都会导致通道发生错误，客户端无法发出随后的调用，只能关闭代理。如果客户端包含了一个单例实例的会话，那么会话会终止。

错误

异常的根本问题在于它们与特定的技术紧密结合，因此无法跨越服务边界被调用两端共享。若要考虑良好的互操作性，我们就需要将基于特定技术的异常映射为某种与平台无关的错误信息。这种表现形式就是所谓的SOAP错误（SOAP Fault）。SOAP错误基于一种行业标准，它不依赖于任何一种诸如CLR异常、Java异常或C++异常之类的特定技术的异常。若要为了抛出一个SOAP错误（或者简称错误），服务就不能抛出一个传统的CLR异常，而是抛出一个FaultException<T>类的实例，它的定义如例6-1所示：

 

http://book.csdn.net/bookfiles/628/10062820199.shtml