Fork me on GitHub

(Moved to #clojure which seems more appropriate)


Does anyone know why does core.async print errors in go blocks to stderr? I could not find it anywhere... (See the 2nd part of the post below, under Update, using clj to test the behavior)


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.


Recently rust library async-std introduce a new runtime, which can detect if a thread is blocking, so it doesn't need distinguish async/block anymore. Is this possible for core.async?


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


I've just published "Error handling in Clojure Core.Async" focusing on the higher-level constructs such as pipeline and transduce and am looking for feedback from people that know core.async much better then me, i.e. you. Please help! Thank you!

Charles Fourdrignier15:12:28

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