Exception和Error都是继承了Throwable类，在Java中只有Throwable类型的实例才可以被抛出（throw）或者捕获（catch），它是异常处理机制的基本组成类型。
Exception和Error体现了Java平台设计者对不同异常情况的分类。Exception是程序正常运行中，可以预料的意外情况，可能并且应该被捕获，进行相应处理。
Error是指在正常情况下，不大可能出现的情况，绝大部分的Error都会导致程序（比如JVM自身）处于非正常的、不可恢复状态。既然是非正常情况，所以不便于也不需要捕获，常 见的比如OutOfMemoryError之类，都是Error的子类。出现就fail了。
Exception又分为可检查（checked）异常和不检查（unchecked）异常，可检查异常在源代码里必须显式地进行捕获处理，这是编译期检查的一部分。前面我介绍的不可查 的Error，是Throwable不是Exception。检查的话就是编译期间。
不检查异常就是所谓的运行时异常，类似 NullPointerException、ArrayIndexOutOfBoundsException之类，通常是可以编码避免的逻辑错误，具体根据需要来判断是否需要捕 获，并不会在编译期强制要求。
NoClassDefFoundError和ClassNotFoundException有什么区别?
前者属于编译存在，运行不存在。
后者属于加载失败。
可参考https://www.java67.com/2012/12/noclassdeffounderror-vs-classnotfoundexception-java.html https://www.jianshu.com/p/93d0db07d2e3
现代jdk，在编译时期，会自动生成相应的处理逻辑，比如，自动按照约定俗成close那些扩展了AutoCloseable或者Closeable的 对象。
写try catch也要注意一些地方
这段已经违背了两个原则
第一，尽量不要捕获类似Exception这样的通用异常，而是应该捕获特定异常，在这里是Thread.sleep()抛出的InterruptedException。比如，你可能更希望RuntimeException被扩散出来，而不是被捕获。
第二，不要生吞（swallow）异常。这是异常处理中要特别注意的事情，因为很可能会导致非常难以诊断的诡异情况。要有输出到日志（Logger）之类，
这段代码的问题是无法在分布式系统中找到stacktrack。最好使用产品日志，详细地输出到日志系统里。
虽然有try catch，但是我们还是要尽量在代码逻辑上先“抛出”异常，避免使用try catch，因为它要整理出stacktrack，这也是消耗性能的。
这段filename可能不存在，所以改进为
自定义异常的两点注意事项：
1.是否需要定义成Checked Exception，因为这种类型设计的初衷更是为了从异常情况恢复，作为异常设计者，我们往往有充足信息进行分类。
2.在保证诊断信息足够的同时，也要考虑避免包含敏感信息，因为那样可能导致潜在的安全问题。如果我们看Java的标准类库，你可能注意到类似java.net.ConnectException， 出错信息是类似“ Connection refused (Connection refused)”，而不包含具体的机器名、IP、端口等，一个重要考量就是信息安全。类似的情况在日志中也有，比如，用户数 据一般是不可以输出到日志里面的。
异常机制的性能消耗
try-catch代码段会产生额外的性能开销，或者换个角度说，它往往会影响JVM对代码进行优化，所以建议仅捕获有必要的代码段，尽量不要一个大的try包住整段的代码；与此同 时，利用异常控制代码流程，也不是一个好主意，远比我们通常意义上的条件语句（if/else、switch）要低效。
Java每实例化一个Exception，都会对当时的栈进行快照，这是一个相对比较重的操作。如果发生的非常频繁，这个开销可就不能被忽略了。
当我们的服务出现反应变慢、吞吐量下降的时候，检查发生最频繁的Exception也是一种思路。
参考杨晓峰老师的《java核心技术》