From 3f4b039e33f2a6da6413bac416be97c1b0738ca8 Mon Sep 17 00:00:00 2001 From: Dylan DPC Date: Thu, 24 Feb 2022 00:37:06 +0100 Subject: [PATCH] word wrpa --- library/std/src/io/error.rs | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/library/std/src/io/error.rs b/library/std/src/io/error.rs index a69062ee2ca..17e2b97545a 100644 --- a/library/std/src/io/error.rs +++ b/library/std/src/io/error.rs @@ -144,13 +144,13 @@ struct Custom { /// /// # Handling errors and matching on `ErrorKind` /// -/// In application code, use `match` for the `ErrorKind` values you are +/// In application code, use `match` for the `ErrorKind` values you are /// expecting; use `_` to match "all other errors". /// -/// In comprehensive and thorough tests that want to verify that a test doesn't -/// return any known incorrect error kind, you may want to cut-and-paste the -/// current full list of errors from here into your test code, and then match -/// `_` as the correct case. This seems counterintuitive, but it will make your +/// In comprehensive and thorough tests that want to verify that a test doesn't +/// return any known incorrect error kind, you may want to cut-and-paste the +/// current full list of errors from here into your test code, and then match +/// `_` as the correct case. This seems counterintuitive, but it will make your /// tests more robust. In particular, if you want to verify that your code does /// produce an unrecognized error kind, the robust solution is to check for all /// the recognized error kinds and fail in those cases.