Re: [boost] Exception Visitor and catch(...)

12 Aug 2006

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

file_iterator::file_iterator()
{
    _root = _path = 0;
    ref = 0;
#ifndef BOOST_NO_EXCEPTIONS
    try{
#endif
    _root = new char[MAX_PATH];
    BOOST_REGEX_NOEH_ASSERT(_root)
    _path = new char[MAX_PATH];
    BOOST_REGEX_NOEH_ASSERT(_path)
    ptr = _path;
    *_path = 0;
    *_root = 0;
    ref = new file_iterator_ref();
    BOOST_REGEX_NOEH_ASSERT(ref)
    ref->hf = _fi_invalid_handle;
    ref->count = 1;
#ifndef BOOST_NO_EXCEPTIONS
    }
    catch(...)
    {
       delete[] _root;
       delete[] _path;
       delete ref;
       throw;
    }
#endif
}

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?

Best,
Oleg Abrosimov.

Ames Andreas wrote:
...
...
-----Original Message-----
From: boost-bounces@lists.boost.org 
[mailto:boost-bounces@lists.boost.org] 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