Day05=Java异常处理+快递柜小程序的MVC架构

异常？

导致程序中断的指令流。
异常给出线程，程序流的路径，灰色的文件是来自依赖库，可以不看，主要是蓝色的是自己写的代码。从上往下看第一个蓝色。

异常类Exception

对错误操作创建了对象，如果没有处理异常，会把异常返回main方法，抛给调用的方法名（JVM虚拟机），处理方案是中断程序。
捕获异常->拦截掉，在try{}catch块里处理

try{
	//可能出现问题
}catch (异常类型1 异常对象1){
	//异常处理
}catch (异常类型2 异常对象2){
	//异常处理
}...
finally{
	//异常统一出口（必定会执行？？）
}

异常的父类：Throwable，它除了Exception还有Error，后者是错误，由JVM发出的错误操作，只能尽量避免无法用代码处理（比如内存溢出）。前者则表示程序中的错误，可以进行try catch的处理。

• RuntimeException运行时异常（非受检异常），在运行时因为参数可能出现的错误。
• 如果出现异常，则会创建一个异常类的实例化对象，如果异常发生在try语句里面，则自动找到匹配的catch来执行，如果没在try中则抛给调用方法
• catch里面做补救
• Exception e 多态
• Java代码占用蓝牙是不会释放，文件也会继续占用，GC只回收内存垃圾，不管硬件。
• finally必然执行的异常统一处理出口，无论是否发生异常都会在最后执行，可以将文件释放放到finally里。
• 如果try里有return，也一定会执行finally，finally是必然执行的。如果走finally之前内存没了，程序直接退出，就不会执行。

return p，复制了p的内存地址，还没返回的时候执行finally，将p的属性修改，那么打印的时候就是修改完的值；如果是基本数据类型（非引用数据类型），return a是备份的，如果再finally修改，那么返回的a还是那个备份的a，值不会改变。【栈：a=10 return时复制出来10这个数据，并要返回它。这个时候再修改也不会返回新的值】

退出

Systm.exit(status:0); //0表示正常退出

• 如果写进catch里，就不会执行finally，这是唯一一种会导致finally不执行的代码。

throws

不做try{}catch直接抛出。
受检异常必须处理，抛出或try{}catch

按住alt+回车可以处理飘红的代码
抛出，由调用者处理。
举例：如果调用方法时传参传错了，比如要用parseInt来处理字符串，parseInt的源码就抛出了NumberFormatException异常，这是RuntimeException。（可以不管）.
异常是否应该抛出？

• 传参导致异常，抛出给方法 throws 无法处理，谁调用谁处理【在/**中备注@throws xxException：因为。。。导致此问题发生

throw？？？

人为抛出的异常，还是要创建异常对象，然后再扔出去。

RuntimeException e = new RuntimeException("不合理");
throw e;

开发时不怎么用。

Execption 区别 ：RuntimeException可以不必用try…catch处理，由JVM处理

自定义异常类（了解）

e栈快递柜代码结构

• v视图 欢迎，菜单，子菜单
• D数据存取 DAO层是所有的快递数组操作 bean是单个快递包裹对象
• C调度逻辑，根据视图接收到的用户输入，调度数据
• 取出来删掉又存进去 多余操作 使mvc更圆润（异地传输）