什么是错误，什么是异常，Exception是干什么的

我的理解是：
错误是程序员弄出来的bug。
异常是没有办法预期的偶然错误。
Exception是Java用来表示程序出错的机制，出错可能是错误也可能是异常。

错误是程序员调用接口的时候没有满足这个接口的契约，所以是bug，所以是错误。
异常是程序员按照接口的要求去进行调用了，然后还是出错了，所以不是调用者的责任，所以不算调用者的bug，所以对调用者来说是不寻常的，无法预期的，是异常。
Exception在Java中同时用来表达这两个概念。

对于错误抛出的Exception，只需要一种Exception，就是错误Exception，专门表示这个是错误。然后把代码的接口契约在Exception中重申一遍。
对于异常抛出的Exception，应该是在一个Exception的类层次中的一个，try catch的代码可能根据Exception的种类进行不同的retry或者别的应付异常的办法，或者给出有意义的提示。

错误只能出现在程序员开发期间，一旦是发布部署了，对于错误的捕捉提示应该就是“程序内部错误”
异常则是有可能出现在发布部署之后，提示应该是尽可能的有意义，让用户在产生了这种异常之后进行自己的应付策略。

如果一个Exception的抛出条件是可检测的，比如可以检测文件是否存在，那么打开不存在的文件就是错误，如果是不可检测的，比如没有检查文件是否存在的接口，则Exception表达的是异常。

————————————————————————

一个Java初学者看过Dbc之后的一点胡言乱语。

我觉得java doc比你讲的更让我容易理解些。

不知道你所谓的错误跟Error类有没有关系。你这么说很容易引起混淆的。

错误处理：

不知道你用什么来应对程序出错的情况。从返回错误号到返回错误对象，从设置全局错误号到setjmp longjmp，从使用异常到知道不使用异常，似乎错误处理总是一件因为很难考虑，从而不知如何应对，进而往往被忽略的东西。

我们是否需要错误处理？答案当然是肯定的。无论你写的是什么样的程序，都需要一个很好的品质。对于高性能的系统级别的软件，我不大清楚那个世界之中应该如何做才能满足要求。近日研究了一下java中的Exception，也就是高级语言中的Exception，所以对于这种普通应用的错误处理稍微比以前多了解了一点，在这里和大家分享一下。

我首先要区分的是错误出现时间：
1 开发的时候
2 发布了之后

对于这两个情况我们处理的办法是完全不一样的。对于开发的时候，Exception出现了，我们会去找代码中的错误，然后通过对代码的修改把出错的地方调试好。对于发布了之后，我们对于那个时候的错误是无法预期的。因为原因是无法与其的，所以我们不能通过修改代码达到修正错误的目的。这个时候利用的就是Exception的层次，通过对可疑代码进行try，catch可能的Exception，并且通过Exception的类型大概的了解了出错的原因，然后根据这么一点点的信息进行可能的应对。

我们应对两种时间出现的Exception的办法是截然不同的，而Exception在这两种场合下的职责也是不同的。对于开发的时候，Exception主要的目的是让程序员了解错误是出在了哪里，是怎么一回事。对于发布了之后的情况，Exception主要是通过其自身的类型，选择程序员预先猜测的catch。然后catch的代码之中有可能是retry这个操作，或者抛出一个比较明确的对话框给用户，让用户去面对出错的场景，因为出错的时候是他在场，而不是程序员在场。

区分了这两种情况，我们也就把Exception分成了两种，前一种需要的是对于程序员有意义的描述，不一定需要一个类层次。第二种是要让try catch的代码进行分类捕捉，一般需要一个类层次。

区分了错误发生的时间之后，我们来关注错误发生的原因：
从我最近的观点来说，主要要区分的就是错误发生的职责到底是哪个方面的，使调用方，还是执行方。Exception是从执行方给调用方的，对于Exception的类型，描述都是由执行方给出的，因为错误是处在执行方进行执行的过程中的，只有它才知道到底是在一个什么样的情况下发生了一个什么样的错误。
然后我们就把自己比作一个执行方，我们在遇到了一个出错的情况的时候，我们会怎么办。所谓出错，也就是程序执行不下去了，为什么执行不下去了，1 调用方没有满足执行方要正确执行的条件，这些条件可以用一些if语句或者assert来具体表现。 2 在执行方进行“正常”操作的时候（暗含的意思就是调用下层代码的时候没有违背它的契约），执行方要调用的下层代码出现了问题，而执行方根本不知道如何处理。在这两种情况下，对于第一种，我们理解这种错误就是程序员的bug，因为他在写代码的时候没有满足执行方给出的契约。对于第二种，我们理解为真正的异常，虽然有可能这个异常只是下层代码中的一个bug，但是对于调用下层代码的执行方来说，我满足了你要的条件，你还是抛出了Exception，我干不下去了，然后它就把异常传递，或者自己进行一些可能的尝试。
所以对于所有的调用方来说，执行方就是会给出两种Exception，一种反映的是它能肯定的程序员的bug， 一种是它不能肯定，情况不明的异常。对于第一种，我们没得选择就是在编写程序的时候及早发现，如果没有处理，在发布之后对于这种异常只能给出一个“程序内部错误”。对于第二种，我们应该用try catch进行一些尝试，也可能是给用户一个很好的提示，如果不是最终的GUI代码，则还可以选择把异常继续上报。

最后：
其实，这样说来第一种异常就不能说是异常，应该在发现的时候就中断程序，提示开发者。这个就是Assert的行为。也就是说，异常/Exception 不应该用来表示程序员编写的代码对于契约的违背，而且程序员也不一定需要一个Exception才能知道自己哪里搞错了，日志，Assert窗口，别的什么的，都行。为了程序员方便调试，为了程序员能够知道更多信息，这个目的去设计一个异常类层次是不值得的。

sorry，不是同一个事情

taowen说得如果我没理解错，应该是错误、异常
在软件开发中的使用。
其实异常的使用是很重要的。一般的java开发人员很少写异常类。


其实异常的正确使用可以提高软件产品的容错能力。

比如登陆检查的时候，可以使用PasswordNotCoreectExcpetion
UserNotFoundException

这样你的错误处理就不需要在你的业务中判断了，可有统一的错误处理叶面处理。

我的观点是PasswordNotCorrectException如果你是说在登陆的时候抛出的话，应该是对Exception的误用。Exception应该永远不在正常的软件流程中出现。Exception只在真正异常的情况下使用。在登陆的时候返回true, false才是比较正确的办法。如果想要更丰富的内容，返回更多种类的常量。而不是抛出不同的异常。

而且即使你是使用在一个业务方法，如果没有登陆使用，应该算是一个出错的情况了。我觉得我们要建立一个契约的概念，如果你没有登陆就调用业务方法就是对契约的破坏。就是程序员的bug。你永远不用用catch一个异常的办法去修正你的代码，所以你不会catch这样的异常。我的观点是一旦Exception是你不会去Catch的，就不应该存在，至少不应该有一个异常层次。所以从这个观点来说，我觉得Java的Error类下面的那些都是多余。

taowen

我想你的说法在某些方面是正确的。
比如对exception的滥用或者过度使用。

但是，我想有一天你会喜欢这种方法的。

我说的PasswordNotCorrectException是在登陆输入错误密码的情况下抛出的。
这是符合java一场处理机制的。

Exception是可以用于业务处理的。比如有胡在电子商务网站上购买商品，当他提交订单的时候需要检查库存，这个时候可以抛出"库存不足异常".

不过我还是坚持异常不能用于正常的业务过程之中。如果一个业务过程都是正确的预期的执行，应该不出现异常。像这里说的库存检查这个情况，应该是用一个if判断，然后给出提示。而不是先去肯定的作，然后作不了了回过头来抛出异常，觉得是一种不大干净的做法。也就是：
catch可以选择exception从而选择执行路径，但是这种选择功能永远不能代理if，而且也不应该代理if。

你说的有道理；但这是两种不同的做法，如果用if只能在程序逻辑内处理。别的方法调用的时候必须通过返回值确定是没货还是别的问题。

异常程序出错误了。但程序出错误了是异常。有一种异常叫做Error异常。

所以我后来怀疑Error是不是多余了。。。既然我们从来不catch error为什么还要error。头大的东西。我可不能直接去挑战Java的语言设计，我只是一个人微言轻的初学者。