Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-10-08 15:31:02

Alexander Terekhov wrote:
> Peter Dimov wrote:
>> Alexander Terekhov wrote:
>>> Peter Dimov wrote:
>>> [...]
>>>> Right. You want to autodetect whether to operate in a throw mode
>>>> or a nothrow mode. This will never work. :-)
>>> Stop advocating blind use of catch(...), Peter!
>> _In the current language_ there is _nothing wrong_ with
>> catch(...)+rethrow. But I don't advocate it in general, or in the
>> above sentence. I don't know what you mean.
> To begin with,
> "should be wrapped in a try {} catch(...) {} block that ignores
> exceptions"
> I mean.

Right. There is only one way to convert a potentially throwing operation
into a nothrow operation, and that's by ignoring exceptions.

> Now, please click here:
> (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

>> That's quite a different story. What does it mean for a cancel
>> exception to be "unexpected", by the way?
> fclose() is a "may also occur" cancelation point in POSIX (it does
> blatantly violate C++ standard, but "enjoy your life", so to speak).
> In C++, you may want to call it inside some destructor that can be
> called due to thrown exception (some non-cancel one; cancelation is
> disabled once it fires). Will you expect it? I simply say that you
> don't necessarily need to disable/restore cancelation in your dtor.
> You may simply rely on std::expected_exception<> checking "inside"
> fclose().

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. I'd rather have std::exceptions_allowed() that returns false in a
destructor or a throw() function.

Boost list run by bdawes at, gregod at, cpdaniel at, john at