From: jbandela_at_[hidden]
Date: 2001-08-03 18:27:12
In GOTW 61 Herb Sutter writes the following
The Importance of "Big-A" Atomicity
As pointed out by Abrahams and Colvin and others, to guarantee any
kind of exception safety it is essential that certain operations --
notable destructors and deallocation functions -- be required not to
throw. That is, they must be at least A-safe. We rely on this in all
sorts of situations, notably:
- The "do all the work off to the side, and commit using only
nonthrowing operations" method is not possible if there are no
suitable nonthrowing (A-safe) operations.
- The related "create a temporary and Swap()" method, which is the
standard form of exception-safe copy assignment, is not possible
without a nonthrowing (A-safe) Swap().
An interesting point raised by Greg Colvin is that for this reason it
does not appear to be possible to write exception-safe code in Java.
The Java specification currently allows the JVM to throw an exception
at any time at arbitrary points in the program, for example
asynchronously when stop is called on a Thread object. In practice it
isn't that bad, but it is worrisome that the Java specification can
apparently be shown to preclude writing exception-safe code because
there is no way to absolutely guarantee A-safe operations in Java.
-----
Are the statements about arbitrary exceptions precluding the writing
of exception safe code still valid? It seems to me that using
exceptions to interrupt threads would, according to the above
passage, preclude writing guaranteed exception-safe code.
Regards,
John R. Bandela
--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> I have not looked at the threading case in particular, but I do
want to
> weigh in on the side of "exceptions don't have to be errors".
Exceptions are
> appropriate where the execution model and (lack of) efficiency
matches the
> needs of the programmer. I've used exceptions successfully to allow
users to
> cancel long operations in a GUI app: I scattered occasional calls
to the
> function which polled for the cancel keystroke through my
operations, and
> threw an exception when it was found that the user had cancelled.
>
> -Dave
>
> ----- Original Message -----
> From: "Alexander Terekhov" <terekhov_at_d...>
> To: <boost_at_y...>
> Sent: Friday, August 03, 2001 2:07 PM
> Subject: Re: boost.threads [was RE: [boost] Re: sockets /network
programming
> Requirements]
>
>
> >
> > > A good attempt at bypassing the problem, but it doesn't cover
all the
> > > basis. This *ISN'T* really an exception but instead is an
attempt at
> > > program flow control.
> >
> > sorry, it is the same (ISO/IEC 14882:1998(E) pg 291):
> >
> > "Exception handling provides a way of transferring control
> > and information from a point in the execution of a program to
> > an exception handler associated with a point previously passed
> > by the execution."
> >
> > > The problem is that code can still catch these
> > > exceptions, even if you insure they are rethrown. Imagine, for
> > > example, a catch block coded as:
> > >
> > > try
> > > {
> > > }
> > > catch(...)
> > > {
> > > LogError();
> > > exit();
> > > }
> > >
> > > The programmer probably doesn't want LogError() called for this
non-
> > > error, and he definately doesn't want the program to exit.
> >
> > but then his code would never call thread::exit so there
> > will be no problems. also, IMHO catch(...) without "throw;"
> > or program termination is inherently flawed (e.g. who is
> > supposed to delete the object thrown by not so smart pointer,
> > etc) so i do not see any good reasons not to provide
> > exception based thread::exit even w/o catch(...)
> > workarounds.
> >
> > regards,
> > alexander.
> >
> >
> >
> > Info: http://www.boost.org Unsubscribe:
> <mailto:boost-unsubscribe_at_y...>
> >
> > Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
> >
> >
> >