Exception

import javax.naming.AuthenticationException;

/*
	2017-02-20 14:14:02
	异常机制可以使程序中的异常处理代码和正常的业务代码分离，保证代码的优雅，提高程序的健壮性
	try	catch	fianlly	throw	throws
	
	try {
		可能引发异常的代码
	} catch (异常类型 e) {
		处理异常的代码
	}finally {
		回收try打开的物理支援
		总会被执行
	}
	
	throw  抛出实际的异常    
	可以作为单独的语句使用，抛出一个具体的异常对象
	
	throws  在方法签名中使用
	用于声明该方法可以能抛出异常
	
	catch块可以捕获多种类型的异常时在异常之间是用   |   隔开
	捕获多种类型的异常时，异常变量有隐式的final修饰，因此程序不能对异常变量重新赋值 
	
	获取异常信息
	
	getMessage 返回该异常的详细描述字符串
	printStackTrace 将该异常的跟踪栈细信息输出到标准错误输出
	printStackTrace( PrintStream s) 将异常的跟踪栈信息输出到指定输出流
	getStackTrace	返回该异常的跟踪栈信息
	
*/

/*
	2017-02-20 15:20:51
	使用throw声明抛出异常
	当前方法不知道该如何处理这种类型的异常，该异常应该有上一级调用者处理
	如果main方法也不知道如何处理这种类型的异常，也可以使用throws声明抛出异常
	将该异常抛给jvm处理
	
	则jvm 处理方法
	打印异常的跟踪栈信息
	终止程序运行
	
	throws 声明抛出的语法格式仅跟在方法签名之后
	一旦是用throws抛出异常
	程序就无须捕获异常了

	throws声明抛出异常时有一个限制，就是方法重写时，
	子类方法声明抛出的异常类型应该是父类方法声明抛出的异常类型的子类或者相同
	子类方法声明抛出的异常不允许比父类方法声明抛出的异常多
	
	Checked异常，java要求必须显示捕获并处理该异常，或者显示抛出该异常，增加了编程的复杂度
	如果方法中显示声明了抛出Checked异常，将会导致方法签名与异常耦合，如果该方法是重写父类的方法，则该方法抛出的异常还会受到被重写方法所抛出异常的限制
	大部分时候推荐使用Runtime异常，而不使用Checked异常
	
*/

/*
	2017-02-20 15:21:37
		java把所有的非正常情况分为
	--异常Exception
	--错误Error
	它们都继承Throwable 父类
	
	Error错误一般是虚拟机相关的问题，系统崩溃、虚拟机错误、动态链接失败等
	这种错误无法恢复或不可能捕获
	导致程序中断
	程序无法处理这些错误
	
	常见的异常
	IndexOutOfBoundsException
	NumberFormatException
	ArithmeticException 除0异常
	NullPointerException
	
	处理异常时应该先处理小的异常，再处理大的异常
*/

/*
	2017-02-20 15:22:08
	fianlly 回收资源
	java回收机制不会回收任何物理资源，垃圾回收机制只能回收堆内存中对象所占用的内存
	不管try块中的代码是否出现异常，fianlly块总会被执行
	
	finally 块中使用 return 或throw 等  导致方法终止
	将会导致try  catch 块中的return 、throw语句失效
	
	finally块中也包含了一个完整的异常处理流程
	这种在try块、catch块 、 finally 块中包含完整的异常处理流程的情形被称为异常处理的嵌套
	
	异常处理流程代码可以放在任何能放 可执行性代码的地方，因此完整的异常处理流程既可以放在try块，也可以放在catch块，还可以放在finally块
	
	try 关键字后紧跟一对圆括号，可以声明、初始化一个或多个资源
	此处的资源指的是那些必须在程序结束时显示关闭的资源
	try为了可以正常关闭资源，这些资源实现类必须实现 AutoCloseable 或 Closeable 接口   中的close 方法
	
	自动关闭资源的try语句相当于隐式的finally 

*/

/*
	2017-02-20 15:23:08

		
	异常 
	--Checked异常		都是可以在编译阶段被处理的异常，强制程序处理所有的Checked异常
	--Runtime异常		运行时异常
	
	所有的RuntimeException类及其子类的实例被称为Runtime异常
	不是RuntimeException类及其子类的异常实例则被称为Checked异常
	
	java认为Checked异常都是可以被处理、修复的异常，所以必须显示处理Checked异常
	如果程序没有显示处理Checked异常，该程序在编译时就会发生错误，无法通过编译
	
	Checked 异常处理的方式
	--当前方法明确知道异常该如何处理异常，程序应该使用try...catch块开捕获该异常，然后对应的catch块中修复该异常
	--当前放啊不知道如何处理这种异常，应该在定义该方法是声明抛出该异常
	
	Runtime异常则更加灵活，无序显示声明抛出，
	程序需要捕获Runtime异常也可以使用try...catch块来实现
	
	没有完善错误处理的代码根本就不会被执行
	
	try块的业务逻辑代码出现异常，系统自动生成一个异常对象，该异常对象被提交给java运行时环境，这个过程被称为抛出throw异常
	
	java运行时环境受到异常对象时，会寻找处理该异常对象的catch块。找到合适的catch块，就把该异常对象交给catch块处理，这个过程称为捕获catch异常
	
	找不到捕获异常的catch块，则程序运行时环境终止，java程序退出
	
	只要程序执行错误的代码块，系统总会自动生成一个异常对象
	程序没有为这段代码块定义任何的catch块
	则java运行时无法找到处理该异常的catch块
	程序就在此退出
*/
/*
	2017-02-20 15:43:44
	使用throw抛出异常
	系统自动抛出异常，自行抛出异常使用throw语句来完成
	
	系统是否抛出异常，可能需要根据应用的业务需求来决定
	程序中的数据、执行与既定业务需求不符，这就是异常
	
	由于与业务需求不符合而产生的异常，必须由程序员来决定抛出，系统无法抛出这种异常
	
	程序中自行抛出的异常，则应该使用throw语句
	throw语句可以单独使用
	throw抛出的不是异常类，而是一个异常实例
	每次只能抛出一个异常实例
	throw ExceptionInstance；
	
	当java运行时接受到开发者自行抛出的异常时，同样会终止当前的执行流，跳到该异常对应的catch块，有该该catch块来处理该异常
	不管是系统自动抛出的异常，还是程序员手动抛出的异常，
	java运行时环境对异常的处理没有任何差别
	
	throw语句抛出的异常是Checked 异常，
	该throw语句要么处于try块，显示捕获该异常
	要么放在一个带有throws声明抛出的方法中，把该异常交给该方法的调用者处理
	
	throw语句抛出的异常时Runtime异常，则该语句无需放在try块中，也无需放在throws声明抛出的方法中
	程序可以显式使用try...catch  来捕获异常，也可以完全不理会该异常，把异常交给该方法调用者
	
	
	
*/

/*
	2017-02-20 15:59:26
	自定义异常
	用户自定义异常都应该继承Exception 基类
	自定义Runtime异常，则应该继承RuntimeException基类
	
	定义异常类通常需要提供两个构造器
	--无参构造器
	--有参构造器
		该字符串参数作为该异常对象的描述信息，也就是异常对象的getMessage()
*/



/*
	2017-02-20 16:07:35
	catch throw 同时使用
	处理的两种方式
	在出现异常的方法内捕获并处理，
	在方法签名中声明抛出该异常
	
	异常处理分为
	应用后台需要通过日志记录异常发生的详细情况
	应用还需要根据异常向应用使用者传达某种提示
	
*/
/*
	2017-02-20 16:13:13
	捕获一个异常然后接着抛出另一个异常，并把原始的异常信息保存下来是一种典型的链式处理 
	也被称为异常链， 职责链设计模式
*/
/*
	2017-02-20 16:14:58
	异常对象的printStackTrace 方法用于打印异常的跟踪栈信息
	根据printSrackTrace，开发者可以找到异常的源头
	
	异常处理规则
	使用程序代码混乱最小化
	捕获并保留诊断信息
	通知合适的人员
	采用合适的方式结束异常活动
	
*/
/*
	2017-02-20 16:25:10
	不要过度使用异常
	--把异常和普通错误混淆在一次，不在编写任何错误处理代码，而是简单地抛出异常来代替所有的错误处理
	--使用异常处理来代替流程控制
	
	对于完全已知的错误，应该编写处理这种错误的代码
	对于普通错误，应该编写处理这种错误的代码
	只有对外部的、不能确定和预知的运行时错误才使用异常

	异常只应该用于处理非正常的情况，不要使用异常处理来代替正常的流程控制
	对于一些完全可知，而且处理方式清楚的错误，程序应该提供相应的错误处理代码，而不是将其笼统的称为异常
*/
/*
	2017-02-20 16:25:22
	不要使用过于庞大的try块
	try块里放置的大量的代码，业务过于庞大，业务过于复杂，就会造成try中出现异常的可能性大大增加
	倒追分析异常原因的难度也大大增加
	
	在后面的catch中难以针对不同的异常提供不同的处理逻辑
	
	应该分割整多个可能出现的异常段落，放在单独的try块中，并分别捕获
*/

/*
	2017-02-20 17:46:43
	避免使用Catch All语句
	Catch All 是一种异常捕获模块，可以处理所有可能的异常
	所有的异常都采用相同的处理方式，导致无法对不同的异常分类处理，
	这种捕获方式可能将程序中的错误、runtime 异常等可能出现的导致程序终止的乘客全部捕获到
	从而压制了异常
	同时关键的异常也会被 忽略
*/

/*
	2017-02-20 17:50:14
	不要忽略捕获到的异常
	对于已经捕获的异常，catch需要处理并修复这个错误，catch 不能为空
	
	处理异常，对异常进行合适的修复，然后绕过执行，或者友好提示等，Checked 异常应该尽量的修复
	重新抛出异常，抛给上层的调用者
	在核实的层处理异常
	
	
*/
class myException extends Exception{
	public myException() {
	}
	
	public myException (String string) {
		super(string);  //调用父类的构造器 获得异常对象的详细描述信息
	}
	
}
//自定义运行时异常
class myRuntime extends RuntimeException{
	public myRuntime() {
	}

	public myRuntime(String message) {
		super(message);
		
	}
	
	
	
}


public class Exceptionj {
	public static void main(String[] args) {
		String string  = "sadf";
		System.out.println(string.length());
		
		String[] string2 = {"s","a","d"};
		System.out.println(string2.length);
		
		System.out.println(Math.pow(2,16));
		
	}
}