@ajs are you seeing this in a networked repl? There are a few reasons things in helper threads don't show exceptions at the top level, one is constructs like future that intentionally hold an exception and throw it when you access its value (which is a gotcha if you ignore the return value of a future), and often with networked repl tooling, exceptions in threads other than main can show up in a different place from the main repl interaction (depending on the tooling setup you may never see the output). But I'd agree that saying in an unqualified way "when an exception is thrown on a thread other than the main thread, and nothing there to catch it, nothing happens", is misleading

so I could easily imagine someone who often uses futures, and using eg. cider in emacs for repl based dev, would think that threads silently die

i know about the issues with future but the implication was that if you divide by zero on a go channel, you may never know that it couldn't complete. and in my experience i always see the exception thrown. Nonetheless I have taken the article's advice to write a Thread/setDefaultUncaughtExceptionHandler -- i figure it can't hurt