Re: [boost] Re: std::expected_exception

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-10-09 07:38:27

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?

>>> 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.

> ... and never actually do a reset, to begin with.

This is known and expected. reset() is assumed to give the basic guarantee.
If the reset() attempt fails, the fallback is that the pointer will be
destroyed later, when all weak pointers die. 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.

>> 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.
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".

>>     I'd rather have std::exceptions_allowed() that returns false in a
>> destructor or a throw() function.
>
> std::unwinding(T *) together with std::expected_exception<T>() (T can
> be void meaning "something/unspecified") is almost all what you need.

No. I don't care about unwinding. I don't care about "expected" exceptions.
I only need to know whether I can throw... and that's if I buy into your
argument. I'm not sure I do. Reverse dependencies (low level to high level)
are usually evil.