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: -------