Re: [boost] [Boost.Thread]:considerremoving catch(...) from thread_proxy

From: John Maddock (john_at_[hidden])
Date: 2005-08-31 12:26:55

>> Well that's a good question: I'm just thinking out loud really, the 
>> options
>> are choice or no choice, and if choice then compile-time or runtime?  My 
>> gut
>> feeling is that compile time parameterisation should be used only when
>> there's some real benefit, and I don't see it in this case - there's no 
>> need
>> to make everything a template :-)   No honestly there isn't really :->
>
> Yeah, but as has been pointed out repeatedly, the user can add his own
> handler.

Agreed, I think it's time to give up and accept the inevitable here :-)

>> The reason I threw this one in, is that there was a suggestion (from 
>> Kevlin
>> Henney's thread proposal if I remember correctly) to decouple thread 
>> object
>> creation, from the actual execution of the thread, so that then we can 
>> tweak
>> the threads properties with getters/setters before we execute the thread
>> (think thread priority, scheduling policy etc).
>>
>> Does this make sense or am I barking up the wrong tree?
>
> Usually when I hear "let's make an instance in a special
> not-fully-functional state so we can tweak it with getters and setters
> before we really bring it to life," little alarm bells go off.  It
> complicates the object invariant and injects often-unwanted state into
> the program.  How about using the parameter library to set these
> things up?

Good point, that would be a good match for this kind of task,

John.