对异常处理的深入理解

本是古典何须时尚 2021-12-17 12:49 371阅读 0赞

## 处理程序异常，需要解决以下 3 个问题 ##

1、哪里发生异常？—（try-catch）  
2、谁来处理异常？–(throw-throws上抛、当前方法处理)  
3、如何处理异常？–（打印日志、恢复业务场景、添加异常信息）

## try ##

首先 ， 需要明确在哪里发生异常。在代码中通过 try-catch 来发现异常，但是有些 程序员往往将大段代码定义在一个町，catch 块内 ， 这样非常不利于定位问题，是一种 不负责任的做法。

## catch ##

捕获的异常范围不要太小，尽量包含所有可能出现的异常。

## finally ##

1）finally 代码块的职责不在于对变量进行赋值等操作，而是清 理资源、释放连接、关闭管道流等操作，此时如果有异常也要做 try-catch 。  
2）finally 代码块中使用 return 语旬，使返回值的判断变得复杂，所以避免返回值不 可控，我们切记不要在 finally 代码块中使用 return 语句。  
3）最后分析 try 代码块与锁的关系， lock 方法可能会抛出 unchecked 异常，如果放 在 try 代码块中，必然触发 finally 中的 unlock 方法执行。对未加锁的对象解锁会抛 出 unchecked 异常，如 Illega!MonitorStateException ， 虽然是因为加锁失败而造成程 序中断的，但是真正加锁失败的原因可能会被后者覆盖。所以在町代码块之前调用 lock（） 方法，避免由于加锁失败导致 finally 调用 unlock（） 抛出异常。  
4）Lock、 ThreadLocal 、 InputStream 等这些需要进行强制释放和清除的对象都得在 finally 代码块中进行显式的清理 ， 避免产生内存泄漏，或者资源消耗。  
5）如果 finally 代码块没有 执行，那么有三种可能·：  
①没有进入 try 代码块。  
②·进入 仕y 代码块 ， 但是代码运行中出现了死循环或死锁状态。  
③进入 try 代码块 ， 但是执行了 System.exit（） 操作。

## 总结 ##

1）如果没有对代码块进行try-catch,出现异常时异常之后的代码都不执行。如果加了try-catch,在当前try包裹的代码块之外的后面的代码依然会正常执行。

public class Demo { 
    public static void main(String[] args) { 
    	b();
    	System.out.println("a");
    	try { 
    		b();
    	System.out.println("b");
    	} catch (Exception e) { 
    		// TODO Auto-generated catch block
    		System.out.println("b中出现异常");
    		e.printStackTrace();
    	}
    	System.out.println("c");
    }
    public static void b(){ 
    
    		try { 
    			int i = 0, j = 0;
    			System.out.println(i);
    			int k = i/j ;
    			System.out.println("haha");
    		} catch (Exception e) { 
    			// TODO Auto-generated catch block
    			e.printStackTrace();
    		}			
    		System.out.println("hello");
    		
    	
    }
    }

运行结果：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjcxNDYx_size_16_color_FFFFFF_t_70]

2）如果内层方法有返回值，一旦return，后面的代码就不会执行，只要内层捕获了异常，外层调用该方法后的代码依然能执行。

public class Demo { 
    public static void main(String[] args) { 
    	b();
    	System.out.println("a");
    	try { 
    	boolean bb=	b();
    	System.out.println("b");
    	} catch (Exception e) { 
    		// TODO Auto-generated catch block
    		System.out.println("b中出现异常");
    		e.printStackTrace();
    	}
    	System.out.println("c");
    }
    public static boolean b(){ 
    
    		try { 
    			int i = 0, j = 0;
    			System.out.println(i);
    			int k = i/j ;
    			System.out.println("haha");
    		} catch (Exception e) { 
    			// TODO Auto-generated catch block
    			e.printStackTrace();
    			return false;
    		}			
    		System.out.println("hello");
    		return true;
    	
    }
    }

运行结果：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjcxNDYx_size_16_color_FFFFFF_t_70 1]

3）如果内层方法有异常，加了try-catch后，外层调用该方法后面的代码依然执行，如果不加就不会执行

public class Demo { 
    public static void main(String[] args) { 
    	b();
    	System.out.println("a");
    	
    }
    
    public static void b(){ 
    	
    			try { 
    				int i = 0, j = 0;
    				System.out.println(i);
    				int k = i/j ;
    				System.out.println("haha");
    			} catch (Exception e) { 
    				// TODO Auto-generated catch block
    				e.printStackTrace();
    			}
    		
    	
    }
    
    }

运行结果：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjcxNDYx_size_16_color_FFFFFF_t_70 2]

public class Demo { 
    public static void main(String[] args) { 
    	b();
    	System.out.println("a");
    	
    }
    
    public static void b(){ 
    				int i = 0, j = 0;
    				System.out.println(i);
    				int k = i/j ;
    				System.out.println("haha");
    			
    	
    }
    
    }

运行结果：  
![在这里插入图片描述][20190709190428591.png]

4）如果内层捕获异常，不抛出自定义异常，外层就捕获不到异常。但抛出自定义异常后，该代码块后面的代码都不执行。

public class Demo { 
    public static void main(String[] args) { 
    	try { 
    		b();
    	} catch (Exception e) { 
    		// TODO Auto-generated catch block
    		e.printStackTrace();
    		System.out.println("bb");
    	}
    	System.out.println("a");
    	
    }
    
    public static void b() throws Exception{ 
    				try { 
    					int i = 0, j = 0;
    					System.out.println(i);
    					int k = i/j ;
    					System.out.println("haha");
    				} catch (Exception e) { 
    					// TODO Auto-generated catch block
    					e.printStackTrace();
    				}
    				System.out.println("aa");
    			
    	
    }
    
    }

运行结果：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjcxNDYx_size_16_color_FFFFFF_t_70 3]

public class Demo { 
    public static void main(String[] args) { 
    	try { 
    		b();
    	} catch (Exception e) { 
    		// TODO Auto-generated catch block
    		e.printStackTrace();
    		System.out.println("bb");
    	}
    	System.out.println("a");
    	
    }
    
    public static void b() throws Exception{ 
    				try { 
    					int i = 0, j = 0;
    					System.out.println(i);
    					int k = i/j ;
    					System.out.println("haha");
    				} catch (Exception e) { 
    					// TODO Auto-generated catch block
    					e.printStackTrace();
    				throw new Exception("自定义");
    				}
    				System.out.println("aa");
    			
    	
    }
    
    }

运行结果：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjcxNDYx_size_16_color_FFFFFF_t_70 4]

## DAO层的异常应该向上抛吗？ ##

DAO 不应该把异常处理掉，因为事务的边界不在 DAO 层上，而是在 Service 层上，假如一个业务逻辑调用了两个 DAO 的方法（A、B）组成一个事务体，若 A 正常执行了，而 B 执行时却发生了异常，这时 A 的执行就需要回滚，若将 B 中的异常捕获了，那根本就不知道 B 是正常执行而是异常执行了，也无法处理事务了。

## 事务为什么不会滚呢？ ##

默认spring事务只在发生未被捕获的 runtimeexcetpion时才回滚。  
spring aop 异常捕获原理：被拦截的方法需显式抛出异常，并不能经任何处理，这样aop代理才能捕获到方法的异常，才能进行回滚，默认情况下aop只捕获runtimeexception的异常，但可以通过

配置来捕获特定的异常并回滚  
换句话说在service的方法中不使用try catch 或者在catch中最后加上throw new runtimeexcetpion（），这样程序异常时才能被aop捕获进而回滚  
解决方案：  
方案1.例如service层处理事务，那么service中的方法中不做异常捕获，或者在catch语句中最后增加throw new RuntimeException()语句，以便让aop捕获异常再去回滚，并且在service上层（webservice客户端，view层action）要继续捕获这个异常并处理  
方案2.在service层方法的catch语句中增加：TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();语句，手动回滚，这样上层就无需去处理异常（现在项目的做法）

## throw与throws抛出异常的区别 ##

throws抛出异常，这个异常不一定会出现，只有当程序出现某种错误时，比如除零异常，数组下表越界异常等等，才会引发异常。而throw是当程序运行到这段时，一定会出现异常，并调用异常处理，就像在上面例子中，传入参数为0时就会产生这个异常。在百度上看到有位朋友的回答很确切，throws是“抛弃”，一旦出现异常就将其抛到调用该方法的地方去，让其他人解决这个异常，throw是“产生”，一旦出现异常就处理它。

## 为何RuntimeException不需要捕获 ##

从逻辑的角度来说，checked exceptions和runtime exception是有不同的使用目的的。checked exception用来指示一种调用方能够直接处理的异常情况。而runtime exception则用来指示一种调用方本身无法处理或恢复的程序错误。

checked exception迫使你捕获它并处理这种异常情况。以java.net.URL类的构建器(constructor)为例，它的每一个构建器都会抛出MalformedURLException。MalformedURLException就是一种checked exception。设想一下，你有一个简单的程序，用来提示用户输入一个URL，然后通过这个URL去下载一个网页。如果用户输入的URL有错误，构建器就会抛出一个exception。既然这个exception是checked exception，你的程序就可以捕获它并正确处理:比如说提示用户重新输入。  
　再看下面这个例子:

public void method(){  
    　int [] numbers = { 1, 2, 3 };  
    　int sum = numbers[0] + numbers[3];  
    }

在运行方法method()时会遇到ArrayIndexOutOfBoundsException(因为数组numbers的成员是从0到2)。对于这个异常，调用方无法处理/纠正。这个方法就是runtime exception的情形。上面我已经提到，runtime exception用来指示一种调用方本身无法处理/恢复的程序错误。而程序错误通常是无法在运行过程中处理的，必须改正程序代码。

总而言之，在程序的运行过程中一个checked exception被抛出的时候，只有能够适当处理这个异常的调用方才应该用try/catch来捕获它。而对于runtime exception，则不应当在程序中捕获它。如果你要捕获它的话，你就会冒这样一个风险:程序代码的错误(bug)被掩盖在运行当中无法被察觉。因为在程序测试过程中，系统打印出来的调用堆栈路径(StackTrace)往往使你更快找到并修改代码中的错误。有些程序员建议捕获runtime exception并纪录在log中，我反对这样做。这样做的坏处是你必须通过浏览log来找出问题，而用来测试程序的测试系统(比如Unit Test)却无法直接捕获问题并报告出来。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjcxNDYx_size_16_color_FFFFFF_t_70]: /images/20211213/d2e82f9807184b7d983b4d12977319d5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjcxNDYx_size_16_color_FFFFFF_t_70 1]: /images/20211213/d55ec27f74a3423a9dced479b2691852.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjcxNDYx_size_16_color_FFFFFF_t_70 2]: /images/20211213/48cd77aac0ee4b9e95c73af14c242f61.png
[20190709190428591.png]: /images/20211213/334296f895c445abaf6397734505fa2e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjcxNDYx_size_16_color_FFFFFF_t_70 3]: /images/20211213/281befaa27d24f288c2b9203328e94ed.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjcxNDYx_size_16_color_FFFFFF_t_70 4]: /images/20211213/17fc4db6c3ff4ba585ee2258f4f430bb.png