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

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):

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