Skip to content

Commit 67008ae

Browse files
authored
Merge pull request #4306 from CodaFi/nitz-and-chitz
[Gardening] Update ErrorHandling.rst
2 parents 43fb605 + 51b659f commit 67008ae

File tree

1 file changed

+3
-3
lines changed

1 file changed

+3
-3
lines changed

docs/ErrorHandling.rst

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -52,7 +52,7 @@ for developers to want to handle errors from different operations in
5252
the same basic way, either by reporting the error to the user or
5353
passing the error back to their own clients.
5454

55-
These errors will be the focus on this proposal.
55+
These errors will be the focus of this proposal.
5656

5757
The final two classes of error are outside the scope of this proposal.
5858
A **universal error** is theoretically recoverable, but by its nature
@@ -305,7 +305,7 @@ generalized ``do`` statement::
305305
As with ``switch`` statements, Swift makes an effort to understand
306306
whether catch clauses are exhaustive. If it can determine it is, then
307307
the compiler considers the error to be handled. If not, the error
308-
automatically propagates out out of scope, either to a lexically
308+
automatically propagates out of scope, either to a lexically
309309
enclosing ``catch`` clause or out of the containing function (which must
310310
be marked ``throws``).
311311

@@ -691,7 +691,7 @@ can throw, and so it must also be marked with ``try``::
691691
}
692692

693693
This marking feels redundant. We want functions like
694-
``autoreleasepool`` to feel like statements, but marks inside builtin
694+
``autoreleasepool`` to feel like statements, but marks inside built-in
695695
statements like ``if`` don't require the outer statement to be marked.
696696
It would be better if the compiler didn't require the outer ``try``.
697697

0 commit comments

Comments
 (0)