在我看来,Google的例外替代方案是
C++:断言(表达式)
GO:延迟/恐慌/恢复是在询问此问题后添加的语言功能
多值回报是否足以作为替代方案？为什么"断言"被视为替代品？如果发生错误而未正确处理错误,Google是否认为该程序可以正常运行？
Go不同寻常的功能之一是函数和方法可以返回多个值.这可以用来改进C程序中的几个笨拙的习语:带内错误返回(例如-1表示EOF)和修改参数.
在C中,写入错误由负计数发信号,错误代码在易失性位置分泌.在Go中,Write可以返回一个计数和一个错误:"是的,你写了一些字节但不是全部,因为你填充了设备".包os中*File.Write的签名是:
func (file *File) Write(b []byte) (n int, err Error)并且正如文档所述,当n!= len(b)时,它返回写入的字节数和非零错误.这是一种常见的风格; 有关更多示例,请参阅有关错误处理的部分.
Go函数的返回或结果"参数"可以给出名称并用作常规变量,就像传入参数一样.命名时,它们在函数开始时被初始化为其类型的零值; 如果函数执行不带参数的return语句,则结果参数的当前值将用作返回值.
名称不是强制性的,但它们可以使代码更短更清晰:它们是文档.如果我们命名nextInt的结果,很明显哪个返回int是哪个.
func nextInt(b []byte, pos int) (value, nextPos int) {由于命名结果已初始化并与简单的返回相关联,因此它们可以简化并澄清.这是一个使用它们的io.ReadFull版本:
func ReadFull(r Reader, buf []byte) (n int, err os.Error) {
for len(buf) > 0 && err == nil {
var nr int;
nr, err = r.Read(buf);
n += nr;
buf = buf[nr:len(buf)];
}
return;
}
例外是一个类似的故事.已经提出了许多异常设计,但每种设计都增加了语言和运行时的复杂性.就其本质而言,例外跨越功能,甚至可能是goroutines; 它们具有广泛的影响.人们还担心它们会对图书馆产生什么影响.根据定义,它们与支持它们的其他语言相比具有特殊的经验,表明它们对库和接口规范有深远的影响.很高兴找到一种设计,使它们真正卓越,而不会鼓励常见错误转变为需要每个程序员进行补偿的特殊控制流程.
与泛型一样,例外仍然是一个悬而未决的问题.
决定:
从表面上看,使用例外的好处超过了成本,特别是在新项目中.但是,对于现有代码,异常的引入会影响所有依赖代码.如果异常可以传播到新项目之外,那么将新项目集成到现有的无异常代码中也会出现问题.由于Google的大多数现有C++代码都没有准备好处理异常,因此采用生成异常的新代码相对比较困难. …
来自Dobbs博士:
概念是C++ 0x的核心新功能
即使在削减"概念"之后,下一个C++标准也可能会延迟.遗憾的是,没有C++ 0x(除非你计算C++ 03中的微小修正).我们必须等待C++ 1x,并希望'x'将是一个低位数.有希望,因为C++ 1x现在功能齐全(除了一些国家标准机构有效坚持标准的正式提案中存在的某些功能的可能性).剩下的"全部"是解决突出技术问题和评论的大量工作.
我在1997年至2000年间处于MT和MP安全C++编程的最前沿.我们自己必须做很多事情.令人震惊的是,该标准在9年后并没有解决并发问题.
那有什么大不了的？