[boost] Re: Re:Re:Re:Re:Re:Re:Re:Re:AttemptingresolutionofThreads&ExceptionsIssue

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-08-14 00:44:38

I don't think the amount internal scaffolding can count against the
mechanism unless it was a serious runtime overhead.

The shared_ptr paradigm is easily do-able, with the copy-constructor
exception propagation semantics. I have no doubt in my mind that the user
can adopt a more OO mechanism over a more C++ (copiable type with overloaded
operators) mechanism.

The only question being, what happens at the bridge of the two paradigms to
support an old library? The answer is that the exceptions should be well
documented and can easily be rethrown to match the new paradigm. That means,
for that specific library, all the documented exceptions must be handled
individually without catching references to abstract exception types (for
the same reason that it doesn't work to pass exceptions across threads). The
difference being, the implementor of the boundary point between the library
and the end user can know all exception types, while thread<> cannot, or
cannot feasibly expect the end user to list them. (There can be templates
the ease the implementation of this boundary wrapper as well.)

Of course, the paradigm can be convenient observed from the start of a
project.

----- Original Message -----
From: William E. Kempf
Newsgroups: gmane.comp.lib.boost.devel
Sent: Tuesday, 2002:August:13 4:53 PM
Subject: Re:
Re:Re:Re:Re:Re:Re:Re:Re:AttemptingresolutionofThreads&ExceptionsIssue

From: "Eric Woodruff" <Eric.Woodruff_at_[hidden]>
> Here's another alternative. Instead of relying on the reference-catching
> mechanism, which properly deletes behind the scenes, the user can use
> handles (shared_ptrs) of their exception they want to catch. They can
easily
> allocate their implementation of an abstract exception type on the heap
and
> pass it through correctly.

1)  They can only do this if they are the ones who initiate the initial
throw.  As Mr. Abrahams points out you don't know for sure what the
underlying type truly is if it's a polymorphic type, and so you'd likely
slice the object when copying it into the shared_ptr for "rethrow".

2)  At this point you've put in so much code within the thread for handling
the exception I seriously question whether or not any extra support that I
could add to Boost.Threads would really be of any consequential benefit.

Bill Kempf
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost