软件构造心得(13):用流的泪说明为什么不要滥用unchecked异常

前言

最早最早,我不知道有exception这个东西,之后去博客上找一些不系统的入门教程,在胎儿时接受了不正确的教育一样,觉得exception那么多,又不认识,怪乱七八糟的,反正在我代码上乱加东西可不行。于是曾几何时,我在我的代码里面写满了RuntimeException…一旦违背迅速报错,中间没有任何的乱七八糟
追求短平快的我,即使一开始老师讲过,看了课件之后也是一个劲的狡辩:“那不是还说有些程序员支持有些程序员反对吗,那我这么写没问题的,好像老师最早也就只教了那个嘛,再改我真的吐了(HITlab3真的要命)”,现在想想,真就是下图所示,现在改的代码全是当时年少无知进的水啊…
这篇文章我就讲讲我的心路历程,以及所想所得,吐槽完也只能先继续屎山了,要不真的是每一天都重写一遍代码了
软件构造心得(13):用流的泪说明为什么不要滥用unchecked异常_第1张图片
.当时而现在我只想说,珍爱生命,远离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类型的(自己定义一个最好了),让他时刻提醒着你去处理,每次你使用都爆红告诉你需要去处理可能的特殊情况。
软件构造心得(13):用流的泪说明为什么不要滥用unchecked异常_第2张图片

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

总结

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

你可能感兴趣的:(java,软件构造,笔记)