Boost logo

Boost :

From: Oleg Abrosimov (beholder_at_[hidden])
Date: 2006-08-12 05:23:51

I've searched boost sources for catch(...) and catch (...) clauses and
found many "interesting" examples like that (libs/regex/src/fileiter.cpp):

    _root = _path = 0;
    ref = 0;
    _root = new char[MAX_PATH];
    _path = new char[MAX_PATH];
    ptr = _path;
    *_path = 0;
    *_root = 0;
    ref = new file_iterator_ref();
    ref->hf = _fi_invalid_handle;
    ref->count = 1;
       delete[] _root;
       delete[] _path;
       delete ref;

Note that catch(...) is used only to free resources and this code can be
trivially converted to equally good one but without catch(...) clause
using std::vector for _root and _path and std::auto_ptr for ref

there are many places in boost sourcebase like the above.
It seems that you and Alexander Nasonov have a need to check boost
libraries that you use for such quasi-bugs ;-)

May be there should be a boost-wide macro like BOOST_BROKEN_CATCH_ALL
and some policy to use it through all the codebase?

Oleg Abrosimov.

Ames Andreas wrote:
>> -----Original Message-----
>> From: boost-bounces_at_[hidden]
>> [mailto:boost-bounces_at_[hidden]] On Behalf Of Alexander Nasonov
>> Sent: Friday, July 28, 2006 12:54 PM
>> Subject: Re: [boost] Exception Visitor
>> Please, NO!
>> It's my experience that one catch(...) in a program may be a
>> source of many annoying glitches that users report
>> periodically but developers don't understand what's going on.
>> Removing this often helps. Users start reporting crashes.
>> Most difficult at this stage is to find a user who is able to
>> run Dr. Watson, check 'Create Crash Dump File' and send a
>> dump to developers :)
>> Also worth noting that SEH is not standard C/C++.
> FWIW, I'd like to strongly second that. When catching SEH
> exceptions (like catch(...) does), predictable behaviour is only
> possible if you compile for 'asynchronous exception handling',
> which according to the docs increases the generated code size (I
> don't know about the runtime performance cost). If you compile
> for 'synchronous exception handling' (the more usual thing, I
> believe), you should either be prepared to live with bad cleanup
> of the stack or you install a global SEH-exception handler in
> each thread you start, which does nothing but rethrow and
> therefore crash the app. IMHO, that's nothing a library should
> impose on its apps. Anyway, I fail to see what's the benefit of
> catching segfaults _as the default behaviour_ (that's not to say
> there aren't applications that need to do).
> FWIW again, I won't use a solution which includes catch(...)
> anytime soon (and esp. not if it's done in a pervasive manner).
> cheers,
> aa

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