"Is everyone convinced that propagating the exception into the joining thread is the right behavior or even semantically sensible?"
as a novice user of concurrent programming ( especially when compared to the level here in the boost list ), may i ask whether it is going to be possible to identify the throwing thread or not? here's why i am asking this: let's say i have two threads reading two different files and one of them throws ios_base::failure. this information by itself is meaningless if i catch it in the master thread as i don't have a way of identifying the source. currently, we employ a different mechanism ( using pthreads for now; wishing to switch to boost.threads ): each thread has its own error code in a shared container and if they want to report an error, they write to that container. that way, we know which thread is reporting what error and we can handle it. elegant? not at all but it works so i wonder if propagating exceptions from worker threads to the master thread is gonna have some comparable functionality? ( worker/master architecture is the only model we commonly use so i can't really talk for other thread architectures ). if it doesn't, i think the best a programmer like myself can do is to catch ( ... ) and then still use the shared error code container to resolve the issue am i misunderstanding this mechanism or is it gonna be like i described above? burch
Stefan Seefeld <seefeld <at> sympatico.ca> writes:
Glen Knowles wrote:
Of course you cannot portably pass all exceptions, but you may be able to pass all the ones that use standard types.
And what if the std library or somebody else throws exceptions *derived* from the standard types? If it is not a recognized corba exception what the ACE TAO does is eat it with a catch(...) and then throws a corba system exception on
From: David Abrahams [mailto:dave <at> boost-consulting.com] the other side.
yes, so all exceptions that are allowed to pass have to be explicitely declared as such. If it is not declared, a special standard exception will be thrown (or may be something equivalent to 'unexpected'). If it is derived from a declared one, it will be sliced.
Is everyone convinced that propagating the exception into the joining thread is the right behavior or even semantically sensible?