软件构造心得（13）：用流的泪说明为什么不要滥用unchecked异常

前言

最早最早，我不知道有exception这个东西，之后去博客上找一些不系统的入门教程，在胎儿时接受了不正确的教育一样，觉得exception那么多，又不认识，怪乱七八糟的，反正在我代码上乱加东西可不行。于是曾几何时，我在我的代码里面写满了RuntimeException…一旦违背迅速报错，中间没有任何的乱七八糟
追求短平快的我，即使一开始老师讲过，看了课件之后也是一个劲的狡辩：“那不是还说有些程序员支持有些程序员反对吗，那我这么写没问题的，好像老师最早也就只教了那个嘛，再改我真的吐了（HITlab3真的要命）”，现在想想，真就是下图所示，现在改的代码全是当时年少无知进的水啊…
这篇文章我就讲讲我的心路历程，以及所想所得，吐槽完也只能先继续屎山了，要不真的是每一天都重写一遍代码了

.当时而现在我只想说，珍爱生命，远离unchecked异常。

unchecked大坑举例

比如说大家都知道，我们需要在计划项里面有这么一个东西。getResource.负责获取当前计划项所具有的资源，但是问题在于，如果现在没有资源，怎么处理呢。
很直接的想法就是在调用该方法时，如果尝试在没有资源时获取（我们可以从当前状态或者资源本身来判断这一点），就报错。于是我当时就有了如下看似岁月静好的代码：

/**
	 * 获取计划项所具有的资源，返回一个车厢组成的列表，
	 * 要求已经被分配，如果没有被分配则抛出异常
	 */
	public List<Carriage> getResource() {

		if(this.state.getState() == State.WAITING) {
			throw new RuntimeException("还未分配资源\n");
		}
		checkRep();
		return msr.getResource();
	}

就逻辑很简单，只要违反就抛出一个unchecked异常就完了呗，fallfast，因为的确你也没有什么办法去解决没有资源的事实，返回null也是不好的，没有就是没有，没有时候去调用，抛异常无可厚非。
但事情的关键就在于我抛出的是一个unchecked异常，真就不是浪得虚名，不见棺材不落泪它是真的不管不提醒啊。在写完这行代码之后，我继续写了很久才重新在一个比较复杂的情况用到了这行代码。
在写api的时候，我需要检查资源是否冲突，所以我必须要获取资源，那么这时候问题来了，假如我本人忘记了我自己给自己定的前置的假设“必须要分配”，或者记错成了返回不影响结果而直接调用，没有加任何异常处理机制，那么势必会造成传递效应，这时候一旦你的测试代码再写的不够全面，这个错误就会一直扩散到最最最后面，那后果真就不堪设想（不过我当时是及时发现的）

.....
if(((TrainEntry)preEntry).getResource().contains(r)) {
						return preEntry;
					}
.....

然而，当时愚钝的我只是想着填窟窿，我把所有getResource方法的位置都检查了一遍，确认无误，万事大吉。却没有反思。设想加入我现在在lab4的时候，一定能保证记得getResource的坑吗，设想我记住这个了，那其他的坑我有没有可能只是没有显现？我怎么能保证每时每刻每次都能记下来呢？

答案显而易见了，也是痛苦的，我需要把这种异常改变成为checked类型的（自己定义一个最好了），让他时刻提醒着你去处理，每次你使用都爆红告诉你需要去处理可能的特殊情况。

所以说所谓checked所带来的诸多额外的声明啊，提示啊等等，看似是缺点，实则却是一个时刻提醒程序员，辅助程序员的优点。一定要尽可能地使用checked异常，只要你觉得这个事情可能发生，除非你觉得，真的绝对不会发生了，发生你也管不了了，或者你真的不会再用继续开发了（不管了），你真的不必再考虑以后的事情了（屎山老子再也不堆了！），否则一定要用checked exception，让它成为你代码的一部分！！！

总结

• 除非你真的处理不了了，否则一定要用checked异常来提醒自己
• 不要老是幻想着前置一违反自己就可以为所欲为，实际上屎山往往是自己享受的
• 软件构造实验的痛苦是不可避免的，新的一天，新的bug，新的心得，新的痛苦
• 好好学习，逃离开发岗（✌）