标签：承担 else and 解决 ons cer otf 自己 编译
Atitit.java 异常的使用总结最佳实践 Vo8f
2. 用throw抛出一个异常到catch子句中与通过函数调用传递一个參数两者基本同样。 2
4. RuntimeException跟checked Exception 2
8. Base类and 扩展class 抛出的特别的异常不一样的解决之道 4
11. 列举最经常使用的五种RuntimeException: 5
12. 以下是JDK API中列出的异常类: 除了RuntimeException以外的,都是checked Exception 5
对C程序来说，使用Error Code就能够了。为什么还要引入异常？由于异常不能被忽略。
假设一个函数通过设置一个状态变量或返回错误代码来表示一个异常状态。没有办法保证函数调用者将一定检測变量或測试错误代码。结果程序会从它遇到的异常状态继续执行，异常没有被捕获。程序马上会终止执行。
在C程序中。我们可以用int setjmp( jmp_buf env );和 void longjmp( jmp_buf env, int value );这2个函数来完毕和异常处理相识的功能，可是MSDN中介绍了在C++中使用longjmp来调整stack时不可以对局部的对象调用析构函数。可是对C++程序来说。析构函数是重要的（我就一般都把对象的Delete放在析构函数中）。 <br>所以我们须要一个方法：①可以通知异常状态。又不能忽略这个通知，②而且Searching the stack以便找到异常代码时。③还要确保局部对象的析构函数被Call。而C++的异常处理刚好就是来解决这些问题的。</p> <p>有的地方仅仅实用异常才干解决这个问题。比方说，在当前上下文环境中。无法捕捉或确定的错误类型，我们就得用一个异常抛出到更大的上下文环境其中去。还有，异常处理的使用呢，可以使出错处理程序与“通常”代码分离开来，使代码更简洁更灵活。
另外就是程序不可缺少的健壮性了，异常处理往往在其中扮演着重要的角色。</p>
由于当函数返回时局部对象总是被释放。不管函数是怎样退出的。（仅有一种例外就是当你调用longjmp时。
Longjmp的这个缺点是C++领先支持异常处理的主要原因）
虽然C++首次引入异常的规范
虽然C++首次引入异常的规范，可是Java是强制实施"检查的异常"（Checked Exception）规范的唯一的主流语言
作者:: 老哇的爪子 Attilax 艾龙， EMAIL:1466519819@qq.com
转载请注明来源： http://blog.csdn.net/attilax
这里面确有一些同样点，可是他们也存在着巨大的差异。</p> <p>让我们先从同样点谈起。你传递函数參数与异常的途径能够是传值、传递引用或传递指针。这是同样的。
可是当你传递參数和异常时，系统所要完毕的操作过程则是全然不同的。产生这个差异的原因是：你调用函数时，程序的控制权终于还会返回到函数的调用处，可是当你抛出一个异常时，控制权永远不会回到抛出异常的地方。</p>
微软在Wi n d o w s中引入S E H的主要动机是为了便于操作系统本身的开发。操作系统的开发者使用S E H，使得系统更加强壮。
我们也能够使用S E H。使我们的自己的程序更加强壮。
<br>使用S E H所造成的负担主要由编译程序来承担，而不是由操作系统承担。
<br>当异常块（exception block）出现时，编译程序要生成特殊的代码。编译程序必须产生一些表（ t a b l e）来支持处理S E H的数据结构。 <br>编译程序还必须提供回调（ c a l l b a c k）函数。操作系统能够调用这些函数，保证异常块被处理。
<br>编译程序还要负责准备栈结构和其它内部信息，供操作系统使用和參考。 <br>在编译程序中添加S E H支持不是一件easy的事。不同的编译程序厂商会以不同的方式实现S E H。这一点并不让人感到奇怪。幸亏我们能够不必考虑编译程序的实现细节，而仅仅使用编译程序的S E H功能。
（事实上大多数编译程序厂商都採用微软建议的语法）
Java的Exception分为两类，一类是RuntimeException及其子类。另外一类就是checked Exception。Java要求函数对没有被catch处理掉的checked Exception，须要将其写在函数的声明部分
.net 仅仅有RuntimeException
除了Error与RuntimeException。其它剩下的异常都是你须要关心的，而这些异常类统称为Checked Exception,至于Error与RuntimeException则被统称为Unchecked Exception.
要使用....长处是流程clr,and ide能自己主动生成结构代码...
中建议在遇到可恢复的错误时採用checked异常，遇到不可恢复的异常时採用unchecked异常。
在使用UseCase来描写叙述一个场景的时候，有一个主事件流和n个异常流。异常流可能发生在主事件流的过程，而try语句里面实现的是主事件流，而 catch里面实现的是异常流。在这里Exception不代表程序出现了异常或者错误，Exception仅仅是面向对象化的业务逻辑控制方法。假设没有 明确这一点，那么我觉得并没有真正明确应该怎么使用Java来正确的编程。
而我自己写的程序。会自己定义大量的Exception类，全部这些Exception类都不意味着程序出现了异常或者错误，仅仅是代表非主事件流的发生的， 用来进行那些分支流程的流程控制的。比如你往权限系统中添加一个用户。应该定义1个异常类，UserExistedException。抛出这个异常不代 表你插入动作失败，仅仅说明你碰到一个分支流程，留待后面的catch中来处理这个分支流程。
传统的程序猿会写一个if else来处理。而一个合格的OOP程序猿应该有意识的使用try catch 方式来区分主事件流和n个分支流程的处理，通过try catch，而不是if else来从代码上把不同的事件流隔离开来进行分别的代码撰写
支持Unchecked异常：
沿调用栈向上传播的Checked异常破坏了顶层的方法，由于这些方法必须声明抛出全部它们调用的方法抛出的异常
Check异常的抛出作为方法接口的一部分，这使得加入或移除早期版本号中方法的异常难以实现。
能够在Base类的foo方法中增加抛出ExceptionB的声明，然而，这样就破坏了open-close原则。并且，有时我们没有办法去改动父类，比方当重载一个Jdk里的类的时候。
还有一个可能的做法是在Extend的foo方法中catch住ExceptionB，然后构造一个ExceptionA并抛出。
这是个可行的办法但也仅仅是一个权宜之计。
为了避免在函数声明中写throws部分，在Java项目里面经常能够看到下面代码用来‘吞掉’Exception：
[iii] 在“The Design and Evolution of C++”， Bjarne Stroustrup也提到，相同也基于对这个问题的考虑，c++没有“Static Checking”（checked exceptions）而是採用“Run time Checking”。并且Stroustrup建议。对于丢出新异常D，能够让它从已有的异常中继承，这样既不影响已有代码。新的代码也能够处理它。（这是Stroustrup在1990就作出的结论！
）
这是JAVA认证考试中最常见的题目,其实,runtime exception中最常见的,常常碰到的,也就5,6种,例如以下:
|
ArithmeticException |
int a=0; |
|
ClassCastException： |
Object x = new Integer(0); |
|
IndexOutOfBoundsException |
int [] numbers = { 1, 2, 3 }; |
|
IllegalArgumentException |
int a = Interger.parseInt("test"); |
|
NullPointerExceptionextends |
|
· 除了RuntimeException。其它继承自java.lang.Exception得异常统称为Checked Exception,他们有多少种呢?
|
java.lang.Object |
Anders Hejlsberg论为什么不在c＃引入类似java的checked exceptions - 产品和技术 - 赛迪网.htm
C++处理异常技巧.htm
[转载]JAVA 的checked异常和unchecked异常_4527_新浪博客.htm
Atitit. 异常的使用总结最佳实践java .net php Vo8f
标签：承担 else and 解决 ons cer otf 自己 编译
原文地址：http://www.cnblogs.com/cynchanpin/p/6955788.html
