Java的异常机制有三种：
Error类及其子类表示的是错误，它是不需要程序员处理也不能处理的异常，比如VirtualMachineError虚拟机错误，ThreadDeath线程僵死等。
RuntimeException类及其子类表示的是非受检异常，是系统可能会抛出的异常，程序员可以去处理，也可以不处理，最经典就是NullPointerException空指针异常和IndexOutOfBoundsException越界异常。
Exception类及其子类（不包含非受检异常）表示的是受检异常，这是程序员必须处理的异常，不处理则程序不能通过编译，比如IOException表示I/O异常，SQLException表示数据库访问异常。
我们知道，一个对象的创建要经过内存分配、静态代码初始化、构造函数执行等过程，对象生成的关键步骤是构造函数，那是不是也允许在构造函数中抛出异常呢？从Java语法上来说，完全可以在构造函数中抛出异常，三类异常都可以，但是从系统设计和开发的角度来分析，则尽量不要在构造函数中抛出异常，我们以三种不同类型的异常来说明之。
（1）构造函数抛出错误是程序员无法处理的
在构造函数执行时，若发生了VirtualMachineError虚拟机错误，那就没招了，只能抛出，程序员不能预知此类错误的发生，也就不能捕捉处理。
（2）构造函数不应该抛出非受检异常我们来看这样一个例子，代码如下：
class Person{
public Person（int_age）{
//不满18岁的用户对象不能建立
if（_age＜18）{
throw new RuntimeException（/"年龄必须大于18岁。/"）；
}
}
//看限制级的电影
public void seeMovie（）{
System.out.println（/"看限制级电影/"）；
}
}
这段代码的意图很明显，年龄不满18岁的用户根本不会生成一个Person实例对象，没有对象，类行为seeMovie方法就不可执行，想法很好，但这会导致不可预测的结果，比如我们这样引用Person类。
public static void main（Stringargs）{
Person p=new Person（17）；
p.seeMovie（）；
/*其他的逻辑处理*/
}
很显然，p对象不能建立，因为是一个RuntimeException异常，开发人员可以捕捉也可以不捕捉，代码看上去逻辑很正确，没有任何瑕疵，但是事实上，这段程序会抛出异常，无法执行。这段代码给了我们两个警示：
加重了上层代码编写者的负担
捕捉这个RuntimeException异常吧，那谁来告诉我有这个异常呢？只有通过文档来约束了，一旦Person类的构造函数经过重构后再抛出其他非受检异常，那main方法不用修改也是可以通过测试的，但是这里就可能会产生隐藏的缺陷，而且还是很难重现的缺陷。
不捕捉这个RuntimeException异常，这是我们通常的想法，既然已经写成了非受检异常，main方法的编码者完全可以不处理这个异常嘛，大不了不执行Person的方法！这是非常危险的，一旦产生异常，整个线程都不再继续执行，或者连接没有关闭，或者数据没有写入数据库，或者产生内存异常，这些都是会对整个系统产生影响。
后续代码不会执行
main方法的实现者原本只是想把p对象的建立作为其代码逻辑的一部分，执行完seeMovie方法后还需要完成其他逻辑，但是因为没有对非受检异常进行捕捉，异常最终会抛出到JVM中，这会导致整个线程执行结束后，后面所有的代码都不会继续执行了，这就对业务逻辑产生了致命的影响。
（3）构造函数尽可能不要抛出受检异常
我们来看下面的例子，代码如下：
//父类
class Base{
//父类抛出IOException
public Base（）throws IOException{
throw new IOException（）；
}
}
//子类
class Sub extends Base{
//子类抛出Exception异常
public Sub（）throws Exception{
}
}
就这么一段简单的代码，展示了在构造函数中抛出受检异常的三个不利方面：
导致子类代码膨胀
在我们的例子中子类的无参构造函数不能省略，原因是父类的无参构造函数抛出了IOException异常，子类的无参构造函数默认调用的是父类的构造函数，所以子类的无参构造也必须抛出IOException或其父类。
违背了里氏替换原则
里氏替换原则是说“父类能出现的地方子类就可以出现，而且将父类替换为子类也不会产生任何异常”，那我们回过头来看看Sub类是否可以替换Base类，比如我们的上层代码是这样写的：
public static void main（Stringargs）{
try{
Base base=new Base（）；
}catch（IOException e）{
//异常处理
}
}
然后，我们期望把new Base（）替换成new Sub（），而且代码能够正常编译和运行。非常可惜，编译通不过，原因是Sub的构造函数抛出了Exception异常，它比父类的构造函数抛出的异常范围要宽，必须增加新的catch块才能解决。
可能有读者要问了，为什么Java的构造函数允许子类的构造函数抛出更广泛的异常类呢？这正好与类方法的异常机制相反，类方法的异常是这样要求的：
//父类
class Base{
//父类方法抛出Exception
public void method（）throws Exception{
}
}
//子类
class Sub extends Base{
//子类方法的异常类型必须是父类方法的子类型
@Override
public void method（）throws IOException{
}
}
子类的方法可以抛出多个异常，但都必须是被覆写方法的子类型，对我们的例子来说，Sub类的method方法抛出的异常必须是Exception的子类或Exception类，这是Java覆写的要求。构造函数之所以与此相反，是因为构造函数没有覆写的概念，只是构造函数间的引用调用而已，所以在构造函数中抛出受检异常会违背里氏替换原则，使我们的程序缺乏灵活性。
子类构造函数扩展受限
子类存在的原因就是期望实现并扩展父类的逻辑，但是父类构造函数抛出异常却会让子类构造函数的灵活性大大降低，例如我们期望这样的构造函数。
class Sub extends Base{
public Sub（）throws Exception{
try{
super（）；
}catch（IOException e）{
//异常处理后再抛出
throw e；
}finally{
//收尾处理
}
}
}
很不幸，这段代码编译通不过，原因是构造函数Sub中没有把super（）放在第一句话中，想把父类的异常重新包装后再抛出是不可行的（当然，这里有很多种“曲线”的实现手段，比如重新定义一个方法，然后父子类的构造函数都调用该方法，那么子类构造函数就可以自由处理异常了），这是Java语法限制。
将以上三种异常类型汇总起来，对于构造函数，错误只能抛出，这是程序人员无能为力的事情；非受检异常不要抛出，抛出了“对己对人”都是有害的；受检异常尽量不抛出，能用曲线的方式实现就用曲线方式实现，总之一句话：在构造函数中尽可能不出现异常。
注意 在构造函数中不要抛出异常，尽量曲线救国。