实践中的重构12_不要乱用异常

code review的时候，发现了如下代码。

	/**
	 * 验证一个字符串是一个长度为10，且内容都是数字。
	 * */
	public static boolean validate(String str) {
		if (str == null || str.length() != 10) {
			return false;
		}

		// 纯数字
		try {
			Long.valueOf(str);
		} catch (NumberFormatException ex) {
			return false;
		}

		return true;
	}

第一反应是异常这么用，好奇怪。异常不应该这么用的啊，也许是为了图省事吧。
但是还是应该把异常用在异常情况下，而不是这么误用。这个用法和用异常判断文件的结束没有什么太大的区别。

仔细看了看，不仅仅是异常用的比较奇怪，这个方法是有漏洞的。
明明方法接口的约定是判断长度和数字，但是因为是用Long的valueOf方法，通过异常来实现，结果像"-100000000"这样本来不合法的字符串可以通过这个校验了。

重构后代码如下，直白的完成该方法的接口约定。

	/**
	 * 验证一个字符串是一个长度为10，且内容都是数字。
	 * */
	public static boolean validate2(String str) {
		if (str == null || str.length() != 10) {
			return false;
		}

		char[] data = new char[str.length()];

		str.getChars(0, str.length(), data, 0);

		for (int i = 0; i < data.length; i++) {
			char c = data[i];
			if (c < '0' || c > '9') {
				return false;
			}
		}

		return true;
	}

?????????

通过抛异常，判断数字方法是可取的。
这是一种投机取巧用法，让系统去完成解析的任务，真的挺好的。

投机取巧。
这么说用异常判断文件结尾也可以了。
方法实现和约定不符合也可以了。

如果，某个异常是含意明确的，做为判断的依据并没有问题。只是大多数情况下，都有更好用的办法，所以不用。如果需要，就象你举的例子，没有理由不允许这样用。

你改出来的代码，明显可读性，复杂程度，都比原来的差！

如果，真的不能容忍用异常做判断，可以用正则，好过自已写代码...

这，，为啥不用regex呢？奇怪……
重构出来的代码看起来一坨坨的，觉得可读性很一般。很好奇string转换成char的array的时候为啥要这样写。

为什么不用正则表达式去验证

LZ对重构的理解有偏差..

重构不是改BUG.
重构不是讲解代码规范
重构不是优化代码效率.

重构的目的是在不改变"软件之可察行为"前提下,提高其可理解性,降低其修改成本.

请参考《实现模式》和《重构》

上面怎么说的 说说为什么不能乱用exception?