From 7629628a954b28b52cd59dd555849f6fadce2cd6 Mon Sep 17 00:00:00 2001 From: Jim Pryor Date: Tue, 30 Nov 2010 16:20:59 -0500 Subject: [PATCH] coroutines tweak Signed-off-by: Jim Pryor --- coroutines_and_aborts.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/coroutines_and_aborts.mdwn b/coroutines_and_aborts.mdwn index b9066399..0afd239d 100644 --- a/coroutines_and_aborts.mdwn +++ b/coroutines_and_aborts.mdwn @@ -359,7 +359,7 @@ The matching `try ... with ...` block need not *lexically surround* the site whe in foo bar 0;; - : int = 20 -Here we call `foo bar 0`, and `foo` in turn calls `bar 0`, and `bar` raises the exception. Since there's no matching `try ... with ...` block in `bar`, we percolate back up the history of *who called this function?* and find a matching `try ... with ...` block in `foo`. This catches the error and so then the `try ... with ...` block in `foo` that called `bar` in the first place will evaluate to `20`. +Here we call `foo bar 0`, and `foo` in turn calls `bar 0`, and `bar` raises the exception. Since there's no matching `try ... with ...` block in `bar`, we percolate back up the history of who called that function, and we find a matching `try ... with ...` block in `foo`. This catches the error and so then the `try ... with ...` block in `foo` (the code that called `bar` in the first place) will evaluate to `20`. OK, now this exception-handling apparatus does exemplify the second execution pattern we want to focus on. But it may bring it into clearer focus if we simplify the pattern even more. Imagine we could write code like this instead: -- 2.11.0