Kinda find -> A catch B to be counterintuitive, it doesn't catch B, it throws B. -> A throws B would work. Though we have a problem with throws being a contextual keyword because you also want -> throws B to work presumably and that's doable but annoying.
-
-
I think the analogy is clear but different. ?/throw throws, catch catches (and packages it into a result)
-
Right. But a catch function doesn't necessarily need to catch internally. In fact I suspect catch blocks will be relatively rare compared to function return catches because you'll use ?. And describing what's going on *inside* the function is not something you want on an API
-
I don’t follow your thought process A catch function and a catch block are both “catch” boundaries. Why should a catch function contain catch blocks????
-
Oh, I see your reasoning. No, my point is that with a catch block we care what's inside. With a catch function we do not, you look at functions from the outside as a black box.
-
Why do we care or not care what’s inside in each case?
-
The person looking at a function does not care what it does inside, they only care that it returns a result. "catches" is the exact opposite of what the function does from this perspective. When writing a catch block you actually do care that it catches the result inside it.
-
This is equivocation between the person writing the catch block and the person reading the catch function’s signature, inverted roles 1/2
-
I *do* care that this function catches an error anyway: I need to handle it or throw it before I can get to that sweet -> T type I actually want
- 8 more replies
New conversation -
-
-
Catch is how you create a result, ? opens it up and throws the error further out
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.