github_mirrors/rust-book-cn
1
0
Fork 0
mirror of https://github.com/rust-lang-cn/book-cn.git synced 2025-02-02 23:38:41 +08:00
Code Issues Packages Projects Releases Wiki Activity

Update ch09-03-to-panic-or-not-to-panic.md (#90)

Browse Source
This commit is contained in:
Traffic Tse 2022-08-10 19:06:31 +08:00 committed by GitHub
parent 41c9cd73d0
commit 63103b6943
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
src/ch09-03-to-panic-or-not-to-panic.md
View File

@ -32,7 +32,7 @@ let home: IpAddr = "127.0.0.1".parse().unwrap();
- 在此之后的代码需要摆脱这种有害状态，而不是在每一步都检查这个问题。 - 在此之后的代码需要摆脱这种有害状态，而不是在每一步都检查这个问题。
- 在使用的类型中，没有一个好的方式来编码这些信息。我们将在第 17 章的[“将状态和行为编码为类型”][encoding]<!-- ignore -->一节中通过一个例子来说明我们阐述的意思。 - 在使用的类型中，没有一个好的方式来编码这些信息。我们将在第 17 章的[“将状态和行为编码为类型”][encoding]<!-- ignore -->一节中通过一个例子来说明我们阐述的意思。
如果别人调用你的代码并传递了一个没有意义的值，最好的情况也许就是 `panic!` 并警告使用你的库的人他的代码中有 bug 以便他能在开发时就修复它。类似的，如果你正在调用不受你控制的外部代码，并且它返回了一个你无法修复的无效状态，那么 `panic!` 往往是合适的。 如果别人调用你的代码并传递了一个没有意义的值，最好的情况也许就是 `panic!` 并警告使用你的库的人他的代码中有 bug 以便他能在开发时就修复它。类似地，如果你正在调用不受你控制的外部代码，并且它返回了一个你无法修复的无效状态，那么 `panic!` 往往是合适的。
然而当错误预期会出现时，返回 `Result` 仍要比调用 `panic!` 更为合适。这样的例子包括解析器接收到格式错误的数据，或者 HTTP 请求返回了一个表明触发了限流的状态。在这些例子中，应该通过返回 `Result` 来表明失败预期是可能的，这样将有害状态向上传播，调用者就可以决定该如何处理这个问题。使用 `panic!` 来处理这些情况就不是最好的选择。 然而当错误预期会出现时，返回 `Result` 仍要比调用 `panic!` 更为合适。这样的例子包括解析器接收到格式错误的数据，或者 HTTP 请求返回了一个表明触发了限流的状态。在这些例子中，应该通过返回 `Result` 来表明失败预期是可能的，这样将有害状态向上传播，调用者就可以决定该如何处理这个问题。使用 `panic!` 来处理这些情况就不是最好的选择。