David Abrahams wrote:
on Tue Nov 25 2008, Alexander Terekhov <terekhov-AT-web.de> wrote:
David Abrahams wrote: [...]
OK, great, a second data point. How do you feel about the fact that the upcoming standard requires the catch(...)?
IMO, that's very idiotic, if true.
I think what I wrote was misleading. I should have written that it requires the catch(...) on any platform that doesn't automatically call terminate() as part of the response when an exception escapes from a thread.
I would have thought (not checking the current draft) that the standard (still) requires terminate() when "no matching handler is found". (Note that Boost.Thread's catch(...) *IS* matching handler and so it doesn't fall under that "no matching handler is found" clause). Anyway, how could Boost.Thread call terminate() in ***main/initial*** thread on a "platform that doesn't automatically call terminate() as part of the response when an exception escapes from a thread" (main/initial thread)? No way. BTW, in my view, the response to an exception escaping the thread shall be abort() (at throw point), not terminate(). Related: (Rhetorical question.) When are you standard folks finally going to fix ES (exception specifications) and get rid of very idiotic ES' mandatory catch(...)? The current standard-mandated ES behaviour just hurts and doesn't help anyone except archaic one-phase setjmp/longjmp based "C exceptions" implementors enabled to claim compliance. regards, alexander.