http://d.puremagic.com/issues/show_bug.cgi?id=5317


Sean Kelly <s...@invisibleduck.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


--- Comment #7 from Sean Kelly <s...@invisibleduck.org> 2011-08-30 10:39:03 PDT 
---
If your API requires a cleanup routine to be run then you can either expect the
user to trap any errors and call the cleanup (and break if they fail to do so)
or you can provide a failsafe cleanup mechanism like the one you've outlined
below.  I'm inclined to think that your approach is the right one.

Regarding exception propagating in general... I think there are two reasonable
default behaviors.  One is to do as now where the exception is trapped and
re-thrown when join is called, based on the assumption that if a programmer
cares about the result of a thread he'll explicitly join it at some point (and
holding that reference will prevent premature cleanup of the terminated
thread's exception, if any).  The other is to terminate the app if an unhanded
exception terminates a thread.  I'm inclined to favor the former behavior
because it puts more control in the hands of the programmer, admittedly at the
risk of Bad Things if the app is just poorly written and the unhandled
exception is something important.

Since std.concurrency provides options for the owner thread to receive a
message when spawned threads terminate (via link), I'm going to consider this
issue as addressed.  If you have specific ideas for how the current behavior
could be enhanced, please open a new ticket.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

Reply via email to