learun开发社区 - 力软.net/java快速开发平台官方论坛

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 1431|回复: 2

编程的智慧续

  [复制链接]

9

主题

9

帖子

56

积分

新手上路

Rank: 1

积分
56
发表于 2018-12-21 14:47:02 | 显示全部楼层 |阅读模式
正确处理错误使用有两个分支的if语句,只是我的代码可以达到无懈可击的其中一个原因。这样写if语句的思路,其实包含了使代码可靠的一种通用思想:穷举所有的情况,不漏掉任何一个。

�程序的绝大部分功能,是进行信息处理。从一堆纷繁复杂,模棱两可的信息中,排除掉绝大部分“干扰信息”,找到自己需要的那一个。正确地对所有的“可能性”进行推理,就是写出无懈可击代码的核心思想。这一节我来讲一讲,如何把这种思想用在错误处理上。
错误处理是一个古老的问题,可是经过了几十年,还是很多人没搞明白。Unix的系统API手册,一般都会告诉你可能出现的返回值和错误信息。比如,Linux的read系统调用手册里面有如下内容:
  1. <p><pre>
  2. RETURN VALUE
  3. On success, the number of bytes read is returned...</p><p>On error, -1 is returned, and errno is set appropriately.
  4. <p>
  5. ERRORS</p><p>EAGAIN, EBADF, EFAULT, EINTR, EINVAL, ...
  6. </pre></p>
复制代码

很多初学者,都会忘记检查read的返回值是否为-1,觉得每次调用read都得检查返回值真繁琐,不检查貌似也相安无事。这种想法其实是很危险的。如果函数的返回值告诉你,要么返回一个正数,表示读到的数据长度,要么返回-1,那么你就必须要对这个-1作出相应的,有意义的处理。千万不要以为你可以忽视这个特殊的返回值,因为它是一种“可能性”。代码漏掉任何一种可能出现的情况,都可能产生意想不到的灾难性结果。
对于Java来说,这相对方便一些。Java的函数如果出现问题,一般通过异常(exception)来表示。你可以把异常加上函数本来的返回值,看成是一个“union类型”。比如:
  1. <span class="hljs-function">String <span class="hljs-title">foo</span><span class="hljs-params">()</span> <span class="hljs-keyword">throws</span> MyException </span>{
  2.   ...
  3. }
复制代码

这里MyException是一个错误返回。你可以认为这个函数返回一个union类型:{String, MyException}。任何调用foo的代码,必须对MyException作出合理的处理,才有可能确保程序的正确运行。Union类型是一种相当先进的类型,目前只有极少数语言(比如Typed Racket)具有这种类型,我在这里提到它,只是为了方便解释概念。掌握了概念之后,你其实可以在头脑里实现一个union类型系统,这样使用普通的语言也能写出可靠的代码。
由于Java的类型系统强制要求函数在类型里面声明可能出现的异常,而且强制调用者处理可能出现的异常,所以基本上不可能出现由于疏忽而漏掉的情况。但有些Java程序员有一种恶习,使得这种安全机制几乎完全失效。每当编译器报错,说“你没有catch这个foo函数可能出现的异常”时,有些人想都不想,直接把代码改成这样:
  1. <span class="hljs-keyword">try</span> {
  2.   foo();
  3. } <span class="hljs-keyword">catch</span> (<span class="hljs-keyword">Exception</span> e) {}
复制代码

或者最多在里面放个log,或者干脆把自己的函数类型上加上throws Exception,这样编译器就不再抱怨。这些做法貌似很省事,然而都是错误的,你终究会为此付出代价。

如果你把异常catch了,忽略掉,那么你就不知道foo其实失败了。这就像开车时看到路口写着“前方施工,道路关闭”,还继续往前开。这当然迟早会出问题,因为你根本不知道自己在干什么。

catch异常的时候,你不应该使用Exception这么宽泛的类型。你应该正好catch可能发生的那种异常A。使用宽泛的异常类型有很大的问题,因为它会不经意的catch住另外的异常(比如B)。你的代码逻辑是基于判断A是否出现,可你却catch所有的异常(Exception类),所以当其它的异常B出现的时候,你的代码就会出现莫名其妙的问题,因为你以为A出现了,而其实它没有。这种bug,有时候甚至使用debugger都难以发现。

如果你在自己函数的类型加上throws Exception,那么你就不可避免的需要在调用它的地方处理这个异常,如果调用它的函数也写着throws Exception,这毛病就传得更远。我的经验是,尽量在异常出现的当时就作出处理。否则如果你把它返回给你的调用者,它也许根本不知道该怎么办了。
另外,try { ... } catch里面,应该包含尽量少的代码。比如,如果foo和bar都可能产生异常A,你的代码应该尽可能写成:
  1. <pre class="hljs cpp"><code class="cpp"><span class="hljs-keyword">try</span> {
  2.   foo();
  3. } <span class="hljs-keyword">catch</span> (A e) {...}

  4. <span class="hljs-keyword">try</span> {
  5.   bar();
  6. } <span class="hljs-keyword">catch</span> (A e) {...}
  7. </code></pre>
  8. <p>而不是</p>
  9. <pre class="hljs cpp"><code class="cpp"><span class="hljs-keyword">try</span> {
  10.   foo();
  11.   bar();
  12. } <span class="hljs-keyword">catch</span> (A e) {...}</code></pre>
复制代码

第一种写法能明确的分辨是哪一个函数出了问题,而第二种写法全都混在一起。明确的分辨是哪一个函数出了问题,有很多的好处。比如,如果你的catch代码里面包含log,它可以提供给你更加精确的错误信息,这样会大大地加速你的调试过程。
正确处理null指针穷举的思想是如此的有用,依据这个原理,我们可以推出一些基本原则,它们可以让你无懈可击的处理null指针。

首先你应该知道,许多语言(C,C++,Java,C#,……)的类型系统对于null的处理,其实是完全错误的。这个错误源自于Tony Hoare最早的设计,Hoare把这个错误称为自己的“billion dollar mistake”,因为由于它所产生的财产和人力损失,远远超过十亿美元。

这些语言的类型系统允许null出现在任何对象(指针)类型可以出现的地方,然而null其实根本不是一个合法的对象。它不是一个String,不是一个Integer,也不是一个自定义的类。null的类型本来应该是NULL,也就是null自己。根据这个基本观点,我们推导出以下原则:

  • 尽量不要产生null指针。尽量不要用null来初始化变量,函数尽量不要返回null。如果你的函数要返回“没有”,“出错了”之类的结果,尽量使用Java的异常机制。虽然写法上有点别扭,然而Java的异常,和函数的返回值合并在一起,基本上可以当成union类型来用。比如,如果你有一个函数find,可以帮你找到一个String,也有可能什么也找不到,你可以这样写:
    1. <ul><li><pre class="hljs java"><code class="java"><span class="hljs-function"><span class="hljs-keyword">public</span> String <span class="hljs-title">find</span><span class="hljs-params">()</span> <span class="hljs-keyword">throws</span> NotFoundException </span>{
    2.   <span class="hljs-keyword">if</span> (...) {
    3.     <span class="hljs-keyword">return</span> ...;
    4.   } <span class="hljs-keyword">else</span> {
    5.     <span class="hljs-keyword">throw</span> <span class="hljs-keyword">new</span> NotFoundException();
    6.   }
    7. </code></pre>
    8. </li>
    9. </ul>
    10. <p>}</p>
    11. <pre class="hljs java"></pre>
    复制代码


Java的类型系统会强制你catch这个NotFoundException,所以你不可能像漏掉检查null一样,漏掉这种情况。Java的异常也是一个比较容易滥用的东西,不过我已经在上一节告诉你如何正确的使用异常。 Java的try...catch语法相当的繁琐和蹩脚,所以如果你足够小心的话,像`find`这类函数,也可以返回null来表示“没找到”。这样稍微好看一些,因为你调用的时候不必用try...catch。很多人写的函数,返回null来表示“出错了”,这其实是对null的误用。“出错了”和“没有”,其实完全是两码事。“没有”是一种很常见,正常的情况,比如查哈希表没找到,很正常。“出错了”则表示罕见的情况,本来正常情况下都应该存在有意义的值,偶然出了问题。如果你的函数要表示“出错了”,应该使用异常,而不是null。 - 不要catch NullPointerException。有些人写代码很nice,他们喜欢“容错”。首先他们写一些函数,这些函数里面不大小心,没检查null指针:
  1. <p>void foo() {
  2. String found = find();
  3. int len = found.length();
  4. ...
  5. }</p><pre class="hljs undefined"></pre>
复制代码
当foo调用产生了异常,他们不管三七二十一,就把调用的地方改成这样:
  1. try {
  2. foo();
  3. } catch (Exception e) {
  4. ...
  5. }
复制代码
这样当found是null的时候,NullPointerException就会被捕获并且得到处理。这其实是很错误的作法。首先,上一节已经提到了,`catch (Exception e)`这种写法是要绝对避免的,因为它捕获所有的异常,包括NullPointerException。这会让你意外地捕获try语句里面出现的NullPointerException,从而把代码的逻辑搅得一塌糊涂。另外就算你写成`catch (NullPointerException e)`也是不可以的。由于foo的内部缺少了null检查,才出现了NullPointerException。现在你不对症下药,倒把每个调用它的地方加上catch,以后你的生活就会越来越苦。正确的做法应该是改动foo,而不改调用它的代码。foo应该被改成这样:
  1. <p>void foo() {
  2. String found = find();
  3. if (found != null) {
  4. int len = found.length();
  5. ...
  6. } else {
  7. ...
  8. }
  9. }</p><pre class="hljs javascript"></pre>
复制代码

在null可能出现的当时就检查它是否是null,然后进行相应的处理。- 不要把null放进“容器数据结构”里面。所谓容器(collection),是指一些对象以某种方式集合在一起,所以null不应该被放进Array,List,Set等结构,不应该出现在Map的key或者value里面。把null放进容器里面,是一些莫名其妙错误的来源。因为对象在容器里的位置一般是动态决定的,所以一旦null从某个入口跑进去了,你就很难再搞明白它去了哪里,你就得被迫在所有从这个容器里取值的位置检查null。你也很难知道到底是谁把它放进去的,代码多了就导致调试极其困难。解决方案是:如果你真要表示“没有”,那你就干脆不要把它放进去(Array,List,Set没有元素,Map根本没那个entry),或者你可以指定一个特殊的,真正合法的对象,用来表示“没有”。需要指出的是,类对象并不属于容器。所以null在必要的时候,可以作为对象成员的值,表示它不存在。比如:
  1. class A {
  2. String name = null;
  3. ...
  4. }
复制代码
之所以可以这样,是因为null只可能在A对象的name成员里出现,你不用怀疑其它的成员因此成为null。所以你每次访问name成员时,检查它是否是null就可以了,不需要对其他成员也做同样的检查。- 函数调用者:明确理解null所表示的意义,尽早检查和处理null返回值,减少它的传播。null很讨厌的一个地方,在于它在不同的地方可能表示不同的意义。有时候它表示“没有”,“没找到”。有时候它表示“出错了”,“失败了”。有时候它甚至可以表示“成功了”,…… 这其中有很多误用之处,不过无论如何,你必须理解每一个null的意义,不能给混淆起来。如果你调用的函数有可能返回null,那么你应该在第一时间对null做出“有意义”的处理。比如,上述的函数`find`,返回null表示“没找到”,那么调用`find`的代码就应该在它返回的第一时间,检查返回值是否是null,并且对“没找到”这种情况,作出有意义的处理。“有意义”是什么意思呢?我的意思是,使用这函数的人,应该明确的知道在拿到null的情况下该怎么做,承担起责任来。他不应该只是“向上级汇报”,把责任踢给自己的调用者。如果你违反了这一点,就有可能采用一种不负责任,危险的写法:
  1. public String foo() {
  2. String found = find();
  3. if (found == null) {
  4. return null;
  5. }
  6. }
复制代码
当看到find()返回了null,foo自己也返回null。这样null就从一个地方,游走到了另一个地方,而且它表示另外一个意思。如果你不假思索就写出这样的代码,最后的结果就是代码里面随时随地都可能出现null。到后来为了保护自己,你的每个函数都会写成这样:
  1. public void foo(A a, B b, C c) {
  2. if (a == null) { ... }
  3. if (b == null) { ... }
  4. if (c == null) { ... }
  5. ...
  6. }
复制代码
- 函数作者:明确声明不接受null参数,当参数是null时立即崩溃。不要试图对null进行“容错”,不要让程序继续往下执行。如果调用者使用了null作为参数,那么调用者(而不是函数作者)应该对程序的崩溃负全责。上面的例子之所以成为问题,就在于人们对于null的“容忍态度”。这种“保护式”的写法,试图“容错”,试图“优雅的处理null”,其结果是让调用者更加肆无忌惮的传递null给你的函数。到后来,你的代码里出现一堆堆nonsense的情况,null可以在任何地方出现,都不知道到底是哪里产生出来的。谁也不知道出现了null是什么意思,该做什么,所有人都把null踢给其他人。最后这null像瘟疫一样蔓延开来,到处都是,成为一场噩梦。正确的做法,其实是强硬的态度。你要告诉函数的使用者,我的参数全都不能是null,如果你给我null,程序崩溃了该你自己负责。至于调用者代码里有null怎么办,他自己该知道怎么处理(参考以上几条),不应该由函数作者来操心。采用强硬态度一个很简单的做法是使用`Objects.requireNonNull()`。它的定义很简单:
  1. public static <T> T requireNonNull(T obj) {
  2. if (obj == null) {
  3. throw new NullPointerException();
  4. } else {
  5. return obj;
  6. }
  7. }
复制代码
你可以用这个函数来检查不想接受null的每一个参数,只要传进来的参数是null,就会立即触发`NullPointerException`崩溃掉,这样你就可以有效地防止null指针不知不觉传递到其它地方去。- 使用@NotNull和@Nullable标记。IntelliJ提供了@NotNull和@Nullable两种标记,加在类型前面,这样可以比较简洁可靠地防止null指针的出现。IntelliJ本身会对含有这种标记的代码进行静态分析,指出运行时可能出现`NullPointerException`的地方。在运行时,会在null指针不该出现的地方产生`IllegalArgumentException`,即使那个null指针你从来没有deference。这样你可以在尽量早期发现并且防止null指针的出现。- 使用Optional类型。Java 8和Swift之类的语言,提供了一种叫Optional的类型。正确的使用这种类型,可以在很大程度上避免null的问题。null指针的问题之所以存在,是因为你可以在没有“检查”null的情况下,“访问”对象的成员。Optional类型的设计原理,就是把“检查”和“访问”这两个操作合二为一,成为一个“原子操作”。这样你没法只访问,而不进行检查。这种做法其实是ML,Haskell等语言里的模式匹配(pattern matching)的一个特例。模式匹配使得类型判断和访问成员这两种操作合二为一,所以你没法犯错。比如,在Swift里面,你可以这样写:
  1. let found = find()
  2. if let content = found {
  3. print("found: " + content)
  4. }
复制代码
你从`find()`函数得到一个Optional类型的值`found`。假设它的类型是`String?`,那个问号表示它可能包含一个String,也可能是nil。然后你就可以用一种特殊的if语句,同时进行null检查和访问其中的内容。这个if语句跟普通的if语句不一样,它的条件不是一个Bool,而是一个变量绑定`let content = found`。我不是很喜欢这语法,不过这整个语句的含义是:如果found是nil,那么整个if语句被略过。如果它不是nil,那么变量content被绑定到found里面的值(unwrap操作),然后执行`print("found: " + content)`。由于这种写法把检查和访问合并在了一起,你没法只进行访问而不检查。Java 8的做法比较蹩脚一些。如果你得到一个Optional<String>类型的值found,你必须使用“函数式编程”的方式,来写这之后的代码:
  1. <p>Optional<String> found = find();
  2. found.ifPresent(content -> System.out.println("found: " + content));</p><pre class="hljs python"></pre>
复制代码
这段Java代码跟上面的Swift代码等价,它包含一个“判断”和一个“取值”操作。ifPresent先判断found是否有值(相当于判断是不是null)。如果有,那么将其内容“绑定”到lambda表达式的content参数(unwrap操作),然后执行lambda里面的内容,否则如果found没有内容,那么ifPresent里面的lambda不执行。Java的这种设计有个问题。判断null之后分支里的内容,全都得写在lambda里面。在函数式编程里,这个lambda叫做“[continuation](https://en.wikipedia.org/wiki/Continuation)”,Java把它叫做“[Consumer](https://docs.oracle.com/javase/8/docs/api/java/util/function/Consumer.html)”,它表示“如果found不是null,拿到它的值,然后应该做什么”。由于lambda是个函数,你不能在里面写`return`语句返回出外层的函数。比如,如果你要改写下面这个函数(含有null):
  1. public static String foo() {
  2. String found = find();
  3. if (found != null) {
  4. return found;
  5. } else {
  6. return "";
  7. }
  8. }
复制代码

就会比较麻烦。因为如果你写成这样:
  1. public static String foo() {
  2. Optional<String> found = find();
  3. found.ifPresent(content -> {
  4. return content; // can't return from foo here
  5. });
  6. return "";
  7. }
复制代码
里面的`return a`,并不能从函数`foo`返回出去。它只会从lambda返回,而且由于那个lambda([Consumer.accept](https://docs.oracle.com/javase/8/docs/api/java/util/function/Consumer.html#accept-T-))的返回类型必须是`void`,编译器会报错,说你返回了String。由于Java里closure的自由变量是只读的,你没法对lambda外面的变量进行赋值,所以你也不能采用这种写法:
  1. public static String foo() {
  2. Optional<String> found = find();
  3. String result = "";
  4. found.ifPresent(content -> {
  5. result = content; // can't assign to result
  6. });
  7. return result;
  8. }
复制代码
所以,虽然你在lambda里面得到了found的内容,如何使用这个值,如何返回一个值,却让人摸不着头脑。你平时的那些Java编程手法,在这里几乎完全废掉了。实际上,判断null之后,你必须使用Java 8提供的一系列古怪的[函数式编程操作](http://www.oracle.com/technetwor ... tional-2175753.html):`map`, `flatMap`, `orElse`之类,想法把它们组合起来,才能表达出原来代码的意思。比如之前的代码,只能改写成这样:
  1. <p>public static String foo() {
  2. Optional<String> found = find();
  3. return found.orElse("");
  4. }</p><pre class="hljs javascript"></pre>
复制代码
  1. 这简单的情况还好。复杂一点的代码,我还真不知道怎么表达,我怀疑Java <span class="hljs-number">8</span>的Optional类型的方法,到底有没有提供足够的表达力。那里面少数几个东西表达能力不咋的,论工作原理,却可以扯到functor,continuation,甚至monad等高深的理论…… 仿佛用了Optional之后,这语言就不再是Java了一样。

  2. 所以Java虽然提供了Optional,但我觉得可用性其实比较低,难以被人接受。相比之下,Swift的设计更加简单直观,接近普通的过程式编程。你只需要记住一个特殊的语法<span class="hljs-string">`if let content = found {...}`</span>,里面的代码写法,跟普通的过程式语言没有任何差别。

  3. 总之你只要记住,使用Optional类型,要点在于“原子操作”,使得<span class="hljs-literal">null</span>检查与取值合二为一。这要求你必须使用我刚才介绍的特殊写法。如果你违反了这一原则,把检查和取值分成两步做,还是有可能犯错误。比如在Java <span class="hljs-number">8</span>里面,你可以使用<span class="hljs-string">`found.get()`</span>这样的方式直接访问found里面的内容。在Swift里你也可以使用<span class="hljs-string">`found!`</span>来直接访问而不进行检查。
复制代码

你可以写这样的Java代码来使用Optional类型:
  1. Option<String> found = find();
  2. if (found.isPresent()) {
  3. System.out.println("found: " + found.get());
  4. }
复制代码
  1. <div class="article"><div data-note-content="" class="show-content"><div class="show-content-free" deep="4"><pre class="hljs ruby"><code class="ruby">如果你使用这种方式,把检查和取值分成两步做,就可能会出现运行时错误。<span class="hljs-string">`if (found.isPresent())`</span>本质上跟普通的null检查,其实没什么两样。如果你忘记判断<span class="hljs-string">`found.isPresent()`</span>,直接进行<span class="hljs-string">`found.get()`</span>,就会出现<span class="hljs-string">`NoSuchElementException`</span>。这跟<span class="hljs-string">`NullPointerException`</span>本质上是一回事。所以这种写法,比起普通的null的用法,其实换汤不换药。如果你要用Optional类型而得到它的益处,请务必遵循我之前介绍的“原子操作”写法。


  2. <span class="hljs-comment">### 防止过度工程</span>

  3. 人的脑子真是奇妙的东西。虽然大家都知道过度工程(over-engineering)不好,在实际的工程中却经常不由自主的出现过度工程。我自己也犯过好多次这种错误,所以觉得有必要分析一下,过度工程出现的信号和兆头,这样可以在初期的时候就及时发现并且避免。

  4. 过度工程即将出现的一个重要信号,就是当你过度的思考“将来”,考虑一些还没有发生的事情,还没有出现的需求。比如,“如果我们将来有了上百万行代码,有了几千号人,这样的工具就支持不了了”,“将来我可能需要这个功能,所以我现在就把代码写来放在那里”,“将来很多人要扩充这片代码,所以现在我们就让它变得可重用”……

  5. 这就是为什么很多软件项目如此复杂。实际上没做多少事情,却为了所谓的“将来”,加入了很多不必要的复杂性。眼前的问题还没解决呢,就被“将来”给拖垮了。人们都不喜欢目光短浅的人,然而在现实的工程中,有时候你就是得看近一点,把手头的问题先搞定了,再谈以后扩展的问题。

  6. 另外一种过度工程的来源,是过度的关心“代码重用”。很多人“可用”的代码还没写出来呢,就在关心“重用”。为了让代码可以重用,最后被自己搞出来的各种框架捆住手脚,最后连可用的代码就没写好。如果可用的代码都写不好,又何谈重用呢?很多一开头就考虑太多重用的工程,到后来被人完全抛弃,没人用了,因为别人发现这些代码太难懂了,自己从头开始写一个,反而省好多事。

  7. 过度地关心“测试”,也会引起过度工程。有些人为了测试,把本来很简单的代码改成“方便测试”的形式,结果引入很多复杂性,以至于本来一下就能写对的代码,最后复杂不堪,出现很多bug。

  8. 世界上有两种“没有bug”的代码。一种是“没有明显的bug的代码”,另一种是“明显没有bug的代码”。第一种情况,由于代码复杂不堪,加上很多测试,各种coverage,貌似测试都通过了,所以就认为代码是正确的。第二种情况,由于代码简单直接,就算没写很多测试,你一眼看去就知道它不可能有bug。你喜欢哪一种“没有bug”的代码呢?

  9. 根据这些,我总结出来的防止过度工程的原则如下:

  10. <span class="hljs-number">1</span>. 先把眼前的问题解决掉,解决好,再考虑将来的扩展问题。
  11. <span class="hljs-number">2</span>. 先写出可用的代码,反复推敲,再考虑是否需要重用的问题。
  12. <span class="hljs-number">3</span>. 先写出可用,简单,明显没有bug的代码,再考虑测试的问题。

  13. > 创造这样的精品文章需要很多的精力和咖啡 ;) 如果你喜欢这篇文章,请付款支持。建议金额$5美元或者<span class="hljs-number">30</span>人民币。付款方式请参考[这里](<span class="hljs-symbol">http:</span>/<span class="hljs-regexp">/www.yinwang.org/blog</span>-cn/<span class="hljs-number">2016</span>/<span class="hljs-number">04</span>/<span class="hljs-number">13</span>/pay-blog)。</code>  </pre></div></div></div><div class="show-foot"></div>
复制代码


回复

使用道具 举报

0

主题

4

帖子

148

积分

注册会员

Rank: 2

积分
148
发表于 2019-4-15 05:31:40 | 显示全部楼层
写得很好
回复

使用道具 举报

0

主题

4

帖子

58

积分

注册会员

Rank: 2

积分
58
发表于 2019-4-17 08:20:08 | 显示全部楼层
不错,不错,收藏了。
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

Archiver|手机版|小黑屋|learun开发社区 - 力软.net/java快速开发平台官方论坛 ( 沪ICP备14034717号 )

GMT+8, 2021-10-19 22:23 , Processed in 0.153762 second(s), 25 queries .

Powered by Discuz! X3.4

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表