This commit is contained in:
github-actions[bot] 2022-10-06 07:02:50 +00:00
parent 05d8e1b0bc
commit 441913e7e5
4 changed files with 4 additions and 4 deletions

View File

@ -174,7 +174,7 @@
// ...parser...
}
</code></pre>
<p>deferred函数帮助Parse从panic中恢复。在deferred函数内部panic value被附加到错误信息中并用err变量接收错误信息返回给调用者。我们也可以通过调用runtime.Stack往错误信息中添加完整的堆栈调用信息。</p>
<p>recover函数帮助Parse从panic中恢复。在deferred函数内部panic value被附加到错误信息中并用err变量接收错误信息返回给调用者。我们也可以通过调用runtime.Stack往错误信息中添加完整的堆栈调用信息。</p>
<p>不加区分的恢复所有的panic异常不是可取的做法因为在panic之后无法保证包级变量的状态仍然和我们预期一致。比如对数据结构的一次重要更新没有被完整完成、文件或者网络连接没有被关闭、获得的锁没有被释放。此外如果写日志时产生的panic被不加区分的恢复可能会导致漏洞被忽略。</p>
<p>虽然把对panic的处理都集中在一个包下有助于简化对复杂和不可以预料问题的处理但作为被广泛遵守的规范你不应该试图去恢复其他包引起的panic。公有的API应该将函数的运行失败作为error返回而不是panic。同样的你也不应该恢复一个由他人开发的函数引起的panic比如说调用者传入的回调函数因为你无法确保这样做是安全的。</p>
<p>有时我们很难完全遵循规范举个例子net/http包中提供了一个web服务器将收到的请求分发给用户提供的处理函数。很显然我们不能因为某个处理函数引发的panic异常杀掉整个进程web服务器遇到处理函数导致的panic时会调用recover输出堆栈信息继续运行。这样的做法在实践中很便捷但也会引起资源泄漏或是因为recover操作导致其他问题。</p>

View File

@ -4529,7 +4529,7 @@ src/gopl.io/ch5/defer2/defer.go:15
// ...parser...
}
</code></pre>
<p>deferred函数帮助Parse从panic中恢复。在deferred函数内部panic value被附加到错误信息中并用err变量接收错误信息返回给调用者。我们也可以通过调用runtime.Stack往错误信息中添加完整的堆栈调用信息。</p>
<p>recover函数帮助Parse从panic中恢复。在deferred函数内部panic value被附加到错误信息中并用err变量接收错误信息返回给调用者。我们也可以通过调用runtime.Stack往错误信息中添加完整的堆栈调用信息。</p>
<p>不加区分的恢复所有的panic异常不是可取的做法因为在panic之后无法保证包级变量的状态仍然和我们预期一致。比如对数据结构的一次重要更新没有被完整完成、文件或者网络连接没有被关闭、获得的锁没有被释放。此外如果写日志时产生的panic被不加区分的恢复可能会导致漏洞被忽略。</p>
<p>虽然把对panic的处理都集中在一个包下有助于简化对复杂和不可以预料问题的处理但作为被广泛遵守的规范你不应该试图去恢复其他包引起的panic。公有的API应该将函数的运行失败作为error返回而不是panic。同样的你也不应该恢复一个由他人开发的函数引起的panic比如说调用者传入的回调函数因为你无法确保这样做是安全的。</p>
<p>有时我们很难完全遵循规范举个例子net/http包中提供了一个web服务器将收到的请求分发给用户提供的处理函数。很显然我们不能因为某个处理函数引发的panic异常杀掉整个进程web服务器遇到处理函数导致的panic时会调用recover输出堆栈信息继续运行。这样的做法在实践中很便捷但也会引起资源泄漏或是因为recover操作导致其他问题。</p>

File diff suppressed because one or more lines are too long

File diff suppressed because one or more lines are too long