You are derefing the future which causes the exception thrown in the future to be re-thrown on the thread that derefs it

I see, thank you. But what about the core.async case? Is it the same case due to <!!?

No, that is why you get different behavior

And also why in neither case the jvm uncaught exception handler is triggered, in both cases the exception is caught, so this is also a good example of why using the uncaught exception handler is unreliable

It is global, doesn't compose, and easily unintentionally bypassed

So, in the case of core.async, what is it that catches and prints the exception?

I am not sure, but almost by definition exceptions in a threadpool won't make it to the uncaught exception handler

Because a threadpool running tasks won't let the exception bubble all the way up and kill the thread

Thanks, I will have a look at the thread pool's source code then.

we don't have any non-blocking threads, so I'm not sure if that can translate

a go block gets rewritten into state-machine callbacks attached to channels

Just discover a/split in your post. Thanks ! Note : mbrainz-importer is one of my reference too. ^^