我想知道 在go中处理多层抽象错误
的最佳方法是什么。每当我必须在程序中添加新的级别抽象时,都必须将错误代码从较低级别传输到较高级别。从而日志文件中有重复的通讯,或者我必须记住删除低级别的通讯形式并将其转移到更高级别。下面简单地举例。我跳过了创建每个对象的简短代码,但是我认为您理解我的问题
type ObjectOne struct{
someValue int
}
func (o* ObjectOne)CheckValue()error{
if o.someValue == 0 {
SomeLogger.Printf("Value is 0 error program") // communicate form first level abstraction to logger
return errors.New("Internal value in object is 0")
}
return nil
}
type ObjectTwoHigherLevel struct{
objectOne ObjectOne
}
func (oT* ObjectTwoHigherLevel)CheckObjectOneIsReady() error{
if err := oT.objectOne.CheckValue() ; err != nil{
SomeLogger.Printf("Value in objectOne is not correct for objectTwo %s" , err) // second communicate
return err
}
return nil
}
type ObjectThreeHiggerLevel struct{
oT ObjectTwoHigherLevel
}
func (oTh* ObjectThreeHiggerLevel)CheckObjectTwoIsReady()error{
if err := oTh.oT.CheckObjectOneIsReady() ; err != nil{
SomeLogger.Printf("Value in objectTwo is not correct for objectThree %s" , err)
return err
}
return nil
}
结果在日志文件中,我得到重复的帖子
Value is 0 error program
Value in objectOne is not correct for objectTwo Internal value in object is 0
Value in objectTwo is not correct for objectThree Internal value in object is 0
反过来,如果我仅将某些部分转移err
到更高的级别而没有其他日志,那么我会丢失每个级别发生的信息。
这个怎么解决?私人副本如何沟通?还是我的方法是唯一的好方法?
如果创建一些对象以某种抽象级别在数据库中进行搜索,那么问题将更加令人沮丧,然后在logFile中从同一任务中得到的代码也很少。
编辑: 此答案早于Go 1.13,它提供的功能与所介绍的技术类似。请检查The Go Blog:处理Go
1.13中的错误
。
您应该处理错误,或者不处理错误,而是将错误委托给更高级别(给调用者)。处理错误并返回错误的做法是错误的做法,因为调用方也一样,错误可能会多次处理。
处理错误意味着检查错误并根据该错误做出决定,可能只是将其记录下来,但这也算作“处理”。
如果您选择不处理而是将其委托给更高级别,那可能会很好,但不要仅仅返回您获得的错误值,因为对于没有上下文的调用者而言,它可能毫无意义。
一个非常好的推荐方法是 注释错误 。这意味着您创建并返回一个 新的 错误值,但是旧的错误值也被包装在返回的值中。包装器为包装的错误提供了上下文。
没有为标注错误公共图书馆:github.com/pkg/errors
;
及其godoc:errors
它基本上具有2个功能:1用于包装现有错误:
func Wrap(cause error, message string) error
还有一个用于提取包装错误的方法:
func Cause(err error) error
使用这些,这就是您的错误处理的样子:
func (o *ObjectOne) CheckValue() error {
if o.someValue == 0 {
return errors.New("Object1 illegal state: value is 0")
}
return nil
}
第二层:
func (oT *ObjectTwoHigherLevel) CheckObjectOneIsReady() error {
if err := oT.objectOne.CheckValue(); err != nil {
return errors.Wrap(err, "Object2 illegal state: Object1 is invalid")
}
return nil
}
第三级:仅调用第二级检查:
func (oTh *ObjectThreeHiggerLevel) CheckObjectTwoIsReady() error {
if err := oTh.ObjectTwoHigherLevel.CheckObjectOneIsReady(); err != nil {
return errors.Wrap(err, "Object3 illegal state: Object2 is invalid")
}
return nil
}
请注意,由于这些CheckXX()
方法无法处理错误,因此它们不会记录任何内容。他们正在委派带注释的错误。
如果使用的人ObjectThreeHiggerLevel
决定处理该错误:
o3 := &ObjectThreeHiggerLevel{}
if err := o3.CheckObjectTwoIsReady(); err != nil {
fmt.Println(err)
}
将显示以下不错的输出:
Object3 illegal state: Object2 is invalid: Object2 illegal state: Object1 is invalid: Object1 illegal state: value is 0
不会污染多个日志,并且保留了所有详细信息和上下文,因为我们使用errors.Wrap()
产生了一个错误值,该错误值的格式string
递归为a
,从而以递归方式保留了包装的错误: 错误堆栈 。
您可以在博客文章中阅读有关此技术的更多信息:
戴夫·切尼(Dave Cheney):不要只是检查错误,请妥善处理
如果您喜欢简单的事物和/或不想麻烦外部库,并且可以提取原始错误(准确的错误 值 ,而不是可以的错误 字符串
)也可以,那么您可以只需使用上下文扩展错误并返回此新的扩展错误。
扩展错误最简单的方法是使用fmt.Errorf()
,它允许您创建“
nice”格式的错误消息,并且它会返回一个type值,error
因此您可以直接返回该值。
使用fmt.Errorf()
,这就是错误处理的样子:
func (o *ObjectOne) CheckValue() error {
if o.someValue == 0 {
return fmt.Errorf("Object1 illegal state: value is %d", o.someValue)
}
return nil
}
第二层:
func (oT *ObjectTwoHigherLevel) CheckObjectOneIsReady() error {
if err := oT.objectOne.CheckValue(); err != nil {
return fmt.Errorf("Object2 illegal state: %v", err)
}
return nil
}
第三级:仅调用第二级检查:
func (oTh *ObjectThreeHiggerLevel) CheckObjectTwoIsReady() error {
if err := oTh.ObjectTwoHigherLevel.CheckObjectOneIsReady(); err != nil {
return fmt.Errorf("Object3 illegal state: %v", err)
}
return nil
}
ObjectThreeHiggerLevel
如果决定“处理”它,则会出现以下错误消息:
o3 := &ObjectThreeHiggerLevel{}
if err := o3.CheckObjectTwoIsReady(); err != nil {
fmt.Println(err)
}
将显示以下不错的输出:
Object3 illegal state: Object2 illegal state: Object1 illegal state: value is 0
确保还阅读博客文章:错误处理和执行
现在我打算创建一个更好的错误处理的“应用程序”框架,我试图寻找最佳实践,但没有找到任何 泽西文档:https://Jersey.java.net/nonav/documentation/1.9/user-guide.html#D4E443 Internet上的几个搜索:http://www.codingpedia.org/ama/error-handing-in-rest-api-with-jer
问题内容: 我是新手,发现错误处理非常冗长。我已经读过它的理由并大体上同意,但是似乎在某些地方似乎有更多代码来处理错误而不是实际工作。这是一个(人为的)示例,我在其中传送“ Hello world!”。进入cat并读取并打印输出。基本上,每一行都可以再处理三个错误,而我什至没有处理任何事情。 有没有惯用的,干净的方法来处理此问题?我只是觉得我在想什么。 问题答案: 显然,我们必须处理任何错误。我们
问题内容: 但是那我该如何解决呢? 我的应用程序使用几种类型的文件,我想分配一些静态属性,例如对该文件类型的描述(例如“数据文件”,另一个是“配置文件”,等等)。显然,我会将其放入静态String中,以便无需实例文件即可访问描述(对GUI fi有用)。另一方面,显然所有文件类型都应具有一些通用方法,例如,显然我想从通用超类继承。 在超类中当然是抽象的。 尝试使用超类和接口的组合,但是存在类似的问题
问题内容: 现在我的页面看起来像这样: 我的工作方式可行,但是对于显而易见的事情却非常繁琐和乏味:假设我在代码中间的某个地方调用了一个函数,或者想检查变量的值,或者验证数据库查询返回有效结果,如果失败,我想输出错误?我将不得不制作另一个if / else块,并将所有代码移到新的if块内。这似乎不是一种明智的处理方式。 我一直在阅读有关try / catch的内容,并一直在考虑将我的所有代码放入tr
问题内容: 如果我的应用程序崩溃了,它会挂起几秒钟,然后Android告诉我该应用程序崩溃了,需要关闭。所以我当时想用通用的方式捕获应用程序中的所有异常: 并做一个新的解释,说明应用程序立即崩溃(并且还使用户有机会发送包含错误详细信息的邮件),而不是由于Android而造成了延迟。是否有更好的方法来实现这一目标? 更新: 我使用的是启用了ART的Nexus 5,但我没有注意到我以前遇到的崩溃(我最
问题内容: 几天前我才开始尝试使用node.js。我意识到只要程序中有未处理的异常,Node就会终止。这与我所见过的普通服务器容器不同,在普通服务器容器中,当发生未处理的异常时,只有工作线程死亡,并且容器仍然能够接收请求。这引起了一些问题: 是唯一有效的预防方法吗? 在执行异步过程期间也会捕获未处理的异常吗? 是否存在已经构建的模块(例如发送电子邮件或写入文件),在未捕获的异常的情况下可以利用该模