|
Boost : |
From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-08-12 16:53:11
----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
> I am still left with the impression that I'm missing something. Could you
> illustrate this with an example? A program where moving to exception
> propagation causes exception-related problems.
It's not that exception propagation directly leads to exception-related
problems. It's that it indirectly leads to them by lulling the users into a
misguided perception that exceptions are already handled appropriately.
For an example I'll once again go back to the classic bounded buffer. Let's
imagine that I create a thread that's going to write out several items to
this buffer... a lot more than the buffer can handle with out another thread
reading the values out. Let's also imagine that I create yet another thread
to read this values out and sum them up. The result I'll return to the
caller when he join()s. This is very similar to an async call, but between
the call invocation and the returning of the result there's important
inter-thread interactions going on. With exception propagation I'm
concerned not only that the user may not call join() because he's not
interested in the result, only that the processing occurs, and thus could
never receive the exception. No, I'm also concerned that if exception
propogation is the norm the niave user is lulled into thinking exception
handling is taken care of internally, and thus dead lock occurs when the
writing thread throws an exception while the reading thread is blocked
trying to read a value that will now never be added to the buffer.
On the one hand, I may be over emphasizing the importance of safety again,
but on the other hand I don't see any draw backs to making exception
propogation the non-default mode. When safe to employ, it's trivial to do
so, when it's questionable or unsafe you have to at least consider the
consequences if you enable this.
Bill Kempf
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk