my brain must be going

the go macro generates code that grabs the current binding frame and stashes it away, and resets that frame as the current frame every time the state machine runs

but after the state machine exits, there is no code that saves the current binding frame again, so of course if the binding frame is updated those updates don't propagate across suspend/resumes of goroutines, which explains why a binding around a parking operation explodes

If you write a macro that persists the binding frame to a persistent queue, like SQS, then you get best of both worlds.

(require '[clojure.core.async :as a])
(a/<!! (a/go
         (try :a
           (finally (a/<! (a/go :b))))))
=> :b

seems like a bug to me.

Should I file an issue ? I've seen several try-catch related issues on the JIRA but I have not recognized this one

and you’d expect :a ?

yeah, I’d say that’s a bug

@alexmiller reproduced in [org.clojure/core.async "0.1.346.0-17112a-alpha"] on the JVM

Do you want me to file it?

Yep

will do

There is already a bug for that

In fact many open issues against exception handling in the go macro (which the finally thing is part of)

http://dev.clojure.org/jira/browse/ASYNC-122

@hiredman ah, my bad, just created the issue 😕

will unsubmit

thanks

or leave it, I don't know

I think I can't unsubmit

there are lots of open issues all connected to compilation of try/catch/finally in go blocks being broken

yeah not the first time I got bitten by some corener case

I updated the patch on http://dev.clojure.org/jira/browse/ASYNC-169 with some tests that cover test cases in several other exception handling related issues

I added a patch to http://dev.clojure.org/jira/browse/ASYNC-170 (mentioned yesterday) that fixes parking operations inside bindings