http://d.puremagic.com/issues/show_bug.cgi?id=5317
--- Comment #4 from Sean Kelly <s...@invisibleduck.org> 2011-05-25 16:29:53 PDT --- When the assertion isn't propagated, what's likely happening is that the thread instance is being discarded because the thread is complete. If the app terminates quickly enough then it beats the spawned thread to termination and thread_joinAll() finds the Error waiting to be re-thrown. At the moment, D has fairly lax rules for propagating exceptions that caused a thread to terminate--it's assumed that if you care about the result of a thread you'll call join(), which will always re-throw the exception unless told not to. But if you don't retain a reference to the thread then its result will remain unknown. The exception to this rule is that a spawned thread will receive word that its owner has terminated, and linked threads will notify one another on termination. I could retain these uncaught exceptions and re-throw them to the main thread on app termination, but I don't see much utility in it. If something horrible happens in a thread then the user either wants to shutdown the entire app immediately for fear of memory corruption (which increasingly unlikely with thread-local static data), or he wants specific interested parties to be notified that the thread terminated unexpectedly (which is handled by linking via std.concurrency), or he doesn't care. Perhaps I should add a hook so the user can supply an uncaughtExceptionHandler? I'd avoided doing this in the past because it would interact weirdly with the current behavior of join() re-throwing uncaught exceptions, but it's an option. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------