--- Comment #4 from Sean Kelly <> 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:
------- You are receiving this mail because: -------

Reply via email to