Skip to content

[Gardening] Update ErrorHandling.rst #4306

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 15, 2016
Merged

[Gardening] Update ErrorHandling.rst #4306

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions docs/ErrorHandling.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -52,7 +52,7 @@ for developers to want to handle errors from different operations in
the same basic way, either by reporting the error to the user or
passing the error back to their own clients.

These errors will be the focus on this proposal.
These errors will be the focus of this proposal.

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

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

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

Expand Down