实践中的重构20_一段可笑的异常处理逻辑

Code review也是一个充满乐趣的事情，在一次Code review中，发现了如下代码。

		try {
			f();
		} catch (RuntimeException e) {
			throw new RuntimeException(e);
		}

百思不得其解啊。为什么要捕捉一个RuntimeException又把它抛出去呢。在和原作者充分沟通后，明白了这段代码的来龙去脉。
首先，由其他地方的异常日志推断出这里调用方法f的时候，系统抛出了异常。但是，在错误日志中没有找到关于该异常的日志，于是怀疑异常没有被异常处理器捕捉到，咨询了其他同事，最后确定的方案为参考其他系统的处理方式，在这一层先捕捉住，重新包装一下再抛出去，这样处理的话则异常处理器就可以捕捉住该异常了。
我的问题是，如果异常处理器不能捕捉到原有的异常的话，如此包装再抛出一样是捕捉不到的啊。同事也同意我的看法，但是因为有其他同事的意见在先，以及在其他系统中存在类似的代码，所以就鬼迷心窍的把这段自己都不怎么相信的代码提交了。
事情的真相是这样的。
其他系统的代码如下，该处转换了异常的异常信息。

			try {
				f();
			} catch (RuntimeException e) {
				log(e);
				throw new RuntimeException("调用方法f发生异常", e);
			}

而在错误日志中找不到异常的原因，是因为日志对象的toString方法有一处手误。

		public String toString() {
			StringBuilder sb = new StringBuilder();
			// 把对象信息添加到sb对象中。
			return super.toString();
		}

为什么同事会提交自己都不怎么相信的代码呢？原因如下：
1 轻信了同事的意见。
2 虽然自己也对该方案有所怀疑，但是看到其他系统有类似的代码，就误以为该代码是正确的。
3 没有测试。
事情虽小，教训很多。
该文只是记录软件开发中的一段往事，并不针对任何人。很多软件工程师都会有犯傻的时候，而且所犯的错误低级的让人可笑。重要的不是我们犯了多么低级的错误，重要的是我们从一个个事后人人都认为低级到极限的错误中能得到什么。