[boost] Re: std::expected_exception

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2003-10-09 08:48:49

Peter Dimov wrote:
> 
> Alexander Terekhov wrote:
> > Peter Dimov wrote:
> > [...]
> >> Right. There is only one way to convert a potentially throwing
> >> operation into a nothrow operation, and that's by ignoring
> >> exceptions.
> >
> > Why don't you simply catch KNOWN & EXPECTED exception(s) that you want
> > to swallow?
> 
> And what ARE these known and expected exceptions in this case?

As far as shared_ptr is concerned, NONE. "p_.reset()" shall treated as 
throw()-nothing call. Internally, *it* may catch KNOWN & EXPECTED 
exceptions "you" want to swallow.

// ought to be implicit throw()-nothing
temp_dataset::~temp_dataset() {
  invoke_and_handle_failure< output_error >(
    /* "close-it" */,
    /* "null-handler... do-nothing" */);
  invoke_and_handle_failure< remove_error >(
    /* "remove-it" */,
    /* "logger" */);
}

> 
> >>> Now, please click here:
> >>>
> >>> http://groups.google.com/groups?selm=3E76FB8A.A9C88386%40web.de
> >>> (Subject: Re: [OT] Re: C++ object locks like Java?)
> >>
> >> I did. The example where the exception thrown by the reset() method
> >> of a smart pointer is ignored is legitimate. This is not "blind use
> >> of catch(...)".
> >
> > Sure it is. You can catch pthread_stackovf_e...
> 
> No, in standard C++, I can't. Stack overflow is undefined behavior. My
> program is already broken, catch(...) or not.

Not quite. See "seh2" example. There's nothing broken in it. It isn't 
*portable*; that's it.

> 
> > ... and never actually do a reset, to begin with.
> 
> This is known and expected. reset() is assumed to give the basic guarantee.

That makes no sense to me.

> If the reset() attempt fails, the fallback is that the pointer will be
> destroyed later, when all weak pointers die. 

And what if throws later as well?

>                                              The problem of course only
> arises when reset() can throw, and is a good illustration why it should be
> nothrow, which shared_ptr::reset() is.

Same logic also applies to "p_.reset();"

> 
> >> But what does it mean for a cancel exception to be unexpected, from a
> >> language point of view? A cancel exception always has a handler, its
> >> handler cancels the thread. std::expected_exception<> will always
> >> return true for it.
> >
> > No. http://groups.google.com/groups?selm=3EC258F8.AE7DF214%40web.de
> 
> Meaning "no, if there is throw() specification somewhere"? Duh. Of course.

Not necessarily throw(). 

void oper() throw(int) {
  /**/
  fclose(/*..*/); // doesn't throw; cancel is unexpected
}

void oper() throw(int) {
  /**/
  try {
    fclose(/*..*/); // can throw; cancel IS expected
  }
  catch (std::thread_cancel_request const &) {
    /**/
    std::enable_thread_cancel(); // re-enable cancel state
    std::thread_self().cancel(); // re-inject cancel request
    /**/
  }
}

> That's kind of my point, you effectively want a primitive that tells you "in
> a nothrow region", not whether an exception is "expected", whatever your
> definition of "expected".

See above.

regards,
alexander.