From 51b659f6b34614067048ed9ddf0f8f195af46f14 Mon Sep 17 00:00:00 2001 From: Satish Chauhan Date: Mon, 8 Aug 2016 17:05:26 +0530 Subject: [PATCH] Update ErrorHandling.rst Fix typos in "Error Handling in Swift 2.0" doc --- docs/ErrorHandling.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/ErrorHandling.rst b/docs/ErrorHandling.rst index 7be0ba8af2c7a..8f3ff71cd90fa 100644 --- a/docs/ErrorHandling.rst +++ b/docs/ErrorHandling.rst @@ -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 @@ -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``). @@ -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``.