Re: [boost] [RFC] sticky_exception

From: Andrey Tcherepanov (moyt63c02_at_[hidden])
Date: 2007-09-14 18:13:56

Howard,

This is very interesing idea. I am not sure if it is very useful as part
of widely available framework, but there are the cases when I wished to
have "uncatchable" nuclear exception (preferably able to print out "I am
caught in file_at_line", and then get thrown again). I dealt with a bunch of
old code that is so poisoned with catch(...) statements, and I wish I had
this idea about self-re-throwing exception so I can trace some parts of it
more easily.

Also, such an exception probably is very useful to debugging, so you can
insert it and control "retrowness" dynamically.

And last, but not least, it is probably usable as sort of cancelable
"exit()" call (or thread_exit()?). This is a nice way to get your stack
folded, destructors called all the way up, and you can intercept it and
reset somewhere on top.

Of course, above is my 2 cents

Thanks,
        Andrey

On Thu, 13 Sep 2007 12:23:01 -0600, Howard Hinnant <hinnant_at_[hidden]>  
wrote:

> Hello,
>
> I am requesting comments, both for and against a "sticky exception".
> A sticky exception is one in which once thrown, is very hard to catch
> and handle, without an implicit rethrow.  This represents some
> condition which the thrower believes is sufficiently severe that the
> application (or thread) should clean up resources, but not be allowed
> to continue, even with a catch (...) which does not rethrow.
>
> This can be implemented very simply with a class that owns the right
> to rethrow on destruct, and passes that right along within its copy
> constructor:
>
> class sticky_exception
> {
>      bool owns_;
>      sticky_exception& operator=(const sticky_exception&);
> public:
>      sticky_exception() : owns_(true) {}
>      sticky_exception(sticky_exception& s) : owns_(s.owns_) {s.owns_ =
> false;}
> //    sticky_exception(sticky_exception&& s) : owns_(s.owns_) {s.owns_
> = false;}
>      ~sticky_exception() {if (owns_) {sticky_exception s; throw s;}}
> };
>
> Please go ahead and experiment with such an exception.  I would like
> to hear your experiences both good and bad.  Here is one test driver:
>
[skip]
>
> Note that with the above modification, catch (...) would still always
> automatically rethrow a sticky_exception.  One would need to add the
> extra catch(sticky_exception&) shown above to get back the old
> behavior of catch (...).
>
> Do you see a use for such a class?  Would you use it?  Would you want
> libraries you're using to use it?  Do you have real world example
> conditions which fit this use case?  Or is it just evil (and why)?
>
> Thanks much,
> Howard
>
> _______________________________________________
> Unsubscribe & other changes:  
> http://lists.boost.org/mailman/listinfo.cgi/boost
>