From 7cfdfaa19f5612e559e57da87acc0edf19aac1f3 Mon Sep 17 00:00:00 2001 From: Jim Pryor Date: Tue, 30 Nov 2010 23:53:01 -0500 Subject: [PATCH] coroutines tweak Signed-off-by: Jim Pryor --- coroutines_and_aborts.mdwn | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/coroutines_and_aborts.mdwn b/coroutines_and_aborts.mdwn index a0b35c88..6cc40f0a 100644 --- a/coroutines_and_aborts.mdwn +++ b/coroutines_and_aborts.mdwn @@ -338,6 +338,26 @@ So what I should have said is that when you evaluate the expression: *and that exception is never caught*, then the effect is for the program to immediately stop. +Trivia: what's the type of the `raise (Failure "two")` in: + + if x = 1 then 10 + else raise (Failure "two") + +What's its type in: + + if x = 1 then "ten" + else raise (Failure "two") + +So now what do you expect the type of this to be: + + fun x -> raise (Failure "two") + +How about this: + + (fun x -> raise (Failure "two") : 'a -> 'a) + +Remind you of anything we discussed earlier? /Trivia. + Of course, it's possible to handle errors in other ways too. There's no reason why the implementation of `List.nth` *had* to do things this way. They might instead have returned `Some a` when the list had an nth member `a`, and `None` when it does not. But it's pedagogically useful for us to think about this pattern now. When an exception is raised, it percolates up through the code that called it, until it finds a surrounding `try ... with ...` that matches it. That might not be the first `try ... with ...` that it encounters. For example: -- 2.11.0