does anyone else think it would be nice if an exception thrown in a async/thread thread returned the exception over the channel that it gives you?

that might not be the best way to do it but it seems like there must be a better way than just saying that you should set an UncaughtExceptionHandler

Check out https://github.com/fullcontact/full.async. It provides some nice utilities for core.async, including something like what you’re proposing (go-try)

that's not bad.

I guess it isn't too hard to just write a macro that wraps the thread body with a try catch

it's harder than it sounds and there's no easy answer to this question

for instance full.async doesn't properly handle all error cases in javascript (it catches only Error, and you can throw anything in js)

you can also legitimately ask the question, what happens if a transducer attached to a channel throws ?

so because there's no obvious answer, core.async basically assumes you program defensively everywhere, and just spits out a stacktrace if something goes wrong

core.async try to do the same thing as golang goroutines ?

well, for only the thread macro and for only jvm hosted clojure, it isn't too hard to just write a macro that wraps the body. though, for the general case I suppose there might be more corner cases. Since the thread macro creates the channel and passes it directly back I don't think there's any way for that channel to have a transducer on it.

of course, it would also be easy to just manually wrap your thread body in a try catch and not worry about the extra macro unless you were really trying to make it a widely used pattern.

it's 10 lines of code to build your own version of async/thread

yes, for that special case it's a valid approach

for reference, this message is what made me start thinking about this. Because (probably unintentionally) @noisesmith made it sound like you could deal with what caused your thread to die (presumably an exception) at the place where you're parked on the async/thread. but, if an async/thread throws you just get a nil on the parked channel and no indication of what happened.

You'll probably know what could have caused the thread to die since you might have written the code it runs anyway, but if the thread is running some kind of black box that expects you to be able to handle exceptions, it might be some annoying debugging before you realize what's happening.

Oh, I'd confused the behaviors of future and thread there

ha, I immediately rushed to my repl because I was amazed it worked that way.