java异常处理笔记 - 编程入门网
，我们可以理解
import java.io.*;
public class Trans
{
public static void main(String[] args)
{
test();
}
static void test()
{
// 注意这条语句
throw new Exception(" 故意抛出一个 Exception");
}
}
// 示例程序 2
// 可它却为什么能够编译通过呢？
import java.io.*;
public class Trans
{
public static void main(String[] args)
{
test();
}
static void test()
{
// 注意这条语句
throw new RuntimeException(" 故意抛出一个 RuntimeException");
}
}
java异常处理笔记(6)时间:2011-01-25 blogjava 江苏520对上面两个相当类似的程序，javac 编译时却遭遇了两种截然不同的处理，按理说，第 2 个示例程序也应该像第 1 个示例程序那样，编译时报错！但是 javac 编译它时，却例外地让它通过它，而且在运行时，java 虚拟机也捕获到了这个异常，并且会在 console 打印出详细的异常信息。运行结果如下： java.lang.RuntimeException: 故意抛出一个 RuntimeException
为什么对于 RuntimeException 类型的异常（以及从它派生而出的异常类型），javac 和 java 虚拟机都特殊处理呢？要知道，这可是与“ Java 异常处理模型更严谨和更安全”的设计原则相抵触的呀！究竟是为何呢？这简直让人不法理解呀！主人公阿愚劝大家稍安勿躁，我们不妨换个角度，还是从 C++ 异常处理模型展开对比和分析，也许这能使我们茅塞顿开！ 在 VC 实现的 C++ 异常处理中（基于 SEH 机制之上），一般有两类异常。其一，就是通过 throw 语句，程序员在代码中人为抛出的异常（由于运行时动态地监测到了一个错误）；另外一个呢？就是系统异常，也即前面我们一直重点讨论的 SEH 异常，例如，“被 0 除”，“段存储保护异常”，“无效句柄” 等，这类异常实际上程序员完全可以做得到避免它（只要我们写代码时足够小心，足够严谨，使得写出的代码足够安全可靠），但实际上，这也许无法完全做到，太理想化了。因此，为了彻底解决这种隐患，提高程序整体可靠性（可以容忍程序员留下一些 BUG ，至少不至于因为编码时考虑不周，或一个小疏忽留下的一个小 BUG ，而导致整个应用系统在运行时崩溃！），VC 提供的 C++ 异常处理中，它就能够捕获到 SEH 类型的系统异常。 这类异常在被处理时，实际上它首先会被操作系统的中断系统所接管（也即应用程序出现这类异常时，会导致触发了一个系统“中断”事件），接着，操作系统会根据应用程序中（实际上是 VC 运行库）所设置的一系列“异常”回调函数和其它信息，来把处理该“系统异常”的控制权转交给应用程序层的“ VC 异常处理模型”中。 还记得上一篇文章中，《第 28 集 如何把 SEH 类型的系统异常转化为 C++ 类型的异常》中的方法和技术原理吗？我们不妨回顾一下，“把 SEH 类型的系统异常转化为 C++ 类型的异常”之后，它就提供了一种很好的技术方法，使得 VC 提供的 C++ 异常处理中，完全把“系统异常”的处理容纳到了按 C++ 方式的异常处理之中。 毫无疑问，这种技术大大的好！大大的妙！同样，现在 Java 的异常处理模型中，它理当应该也具备此项技术功能（谁让它是 C++ 的发展呢？），朋友们，阿愚现在是否已经把该问题解释明白了呢？是的，实际上，RuntimeException 异常的作用，就相当于上一篇文章中，阿愚为 C++ 所设计的 seh_exception_base 异常那样，它们在本质上完成同样类似的功能。只不过，Java 语言中，RuntimeException 被统一纳入到了 Java 语言和 J |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
