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;
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?
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).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk