完全赞同王垠对CE的看法，他真正想推荐的应该是typed racket中的union type，这也非常有启发。

我的看法

在调用一个函数的时候，除了正常的返回值，还很可能需要有响应的各种异常，而异常应该是可以被穷举，并且被确保处理的。

在很多时候，异常的处理流程，也是在程序所预先定义好的流程当中。

函数正常执行，获得预期的返回值，这是主流程；但也可以有分支流程，使用异常来触发分支流程是合理的做法。

CE的存在，确保了函数调用者，必须对函数存在的所有分支流程都进行处理。这对提高程序的健壮性非常有帮助。

举个例子，用户注册。

正常的情况下，用户注册是可以成功的，函数会返回注册成功的用户信息；但是也可能不成功，比方说用户名重复，比方说电话号码重复，比方说会员总数到了等等。

这些都是在事先定义的分支流程。

有CE，由编译器来检查这些分支流程都被一一处理了，我觉得这是很好的事情。

CE提供了一套分支流程务必被逐一处理的机制，非常好！

概念

异常与错误是两种不同的概念，比方说，程序报OOM error，这就不是事先定义好的分支流程了。

遇到错误，那么进程就直接挂掉好了。

逐层的通过CE去报，一层层 catch然后重新throw，那就完全木有必要了。

这不是CE适用的场景。

什么时候是异常，什么时候是错误，我觉得go语言也对此做出了很好的示范，只不过在go里面，异常被叫做error，而错误被叫做panic。

要明确

明确异常跟错误的区别，然后对于异常，利用CE，去确保调用方对所有分支流程逐一做显式处理，这是很好的语言特性。

要不要用CE？我的判断标准是相应的异常是否是一个事先定义好的分支流程。

是的话，就用；不是的话，就不用；要么直接挂掉，要么吃掉。

返回值

很多RPC方案，都会有返回值跟错误值的区分。

比方说，thrift Thrift: The Missing Guide。在thrift中，可以这样定义一个远程服务：

 double divide(1:double divisor, 2:double dividend) throws (1:InvalidOperation ouch),

如果除法可以正常计算，那么就返回一个double，如果不能，就抛一个InvalidOperation的异常，并且如果有CE能够确保调用方务必对异常进行处理，是不是挺合理的嘛？

GO的例子

以go为例，上面的thrift接口，实际上是导致以下的代码生成：

type CalculatorDivideResult struct {
    Success *float64            `thrift:"success,0" db:"success" json:"success,omitempty"`
    Ouch    *InvalidOperation `thrift:"ouch,1" db:"ouch" json:"ouch,omitempty"`
}

也就是说，thrift的编译器，会默默的生成一个新的类型，这个类型有两个属性：

一个叫Sucess，类型与函数的正常返回值一致。

一个的命名与类型则与函数的异常一致。

然后，thrift生成出来代码还会有这样：

    if result.Ouch != nil {
        err = result.Ouch
        return
    }
    value = result.GetSuccess()
    return

thrift会默默生成一个『包含正常值+异常值』的隐含类型，远程返回的数据，其实都是这个隐含类型，然后，它会判断这个类型的异常是否有值，如果有值就抛异常，如果没有，就返回正常值。

用go来演示其实不够直观，但我一时间没在网上找到别的语言的thrift生成好的代码，上的代码是从 glycerine/golang-thrift-minimal-example 里面搬的，但我做了简化。

不过，重点是：有一个新类型，这个类型别的都没有，就只用来保存函数的返回值 + 异常。

有异常的时候返回异常，不然就返回返回值。

我们再来看王垠提到的typed rocket中union type的定义 4 Types in Typed Racket:

4.4 Union Types

Sometimes a value can be one of several types. To specify this, we can use a union type, written with the type constructor U.

> (let ([a-number 37])
    (if (even? a-number)
        'yes
        'no))
- : Symbol [more precisely: (U 'no 'yes)]
'no
Any number of types can be combined together in a union, and nested unions are flattened.

(U Number String Boolean Char)

a value can be one of several types，这不就是可以用一个类型，包含多个属性，每个属性都是不同类型，然后，我们使用这个类型的时候，永远都使用其中一个属性的值嘛？

在垠神的pysonar2中也可以看到这样的代码：

              if (realType instanceof UnionType) {
                    for (Type t : ((UnionType) realType).types) {
                        if (t instanceof ClassType) {
                            realType = t;
                            break;
                        }
                    }
                }

（垠神把pysonar2的代码从他的github中拿掉啦~但根据他之前开源出来的版本版权写明了是Apache 2.0，我这里这样引用pysonar2的代码应该没有问题吧？）

如果，我们能够在语言层面，支持Union Type，即一个值可能是多种不同类型，但每次都只能是某个具体类型，然后编译器确保我们对各种类型都做出具体的处理，不会遗漏。

这不是很理想嘛？

总结

我一直都知道thrift中生成隐含类型的实现，但是这次看到垠神的博客，才恍然说，原来这可以是Union Type，一下子从只有两个属性的具体实现，上升到了语言理论的层面。

所以我说：完全赞同王垠对CE的看法，他真正想推荐的应该是typed racket中的union type，这也非常有启发。

感谢垠神，15块钱我付了！

挖坑不填

但是他对于Hejlsberg的评价则无法让人苟同，我会认为这体现了王垠自己的思维局限：他没有搞懂这个世界是存在妥协与无奈的。

Hejlsberg在做无奈的妥协而已，王垠却以为Hejlsberg的逻辑“荒谬”。

这个回答就先这样吧_{`妥协与无奈`部分啥时候等我有空再来写}