From: Vesa Karvonen (vesa.karvonen_at_[hidden])
Date: 2001-06-19 14:26:22
> --- In boost_at_y..., "Vesa Karvonen" <vesa.karvonen_at_h...> wrote:
> > Perhaps someone has invented a better mechanism for dealing
> > with (legacy) objects that might throw in their destructors.
> I don't think it's much of an issue, frankly. Most legacy objects
> will be using legacy libraries which don't throw, thus they need no
> special attention.
Basically a good point - especially with legacy C libraries that have been
migrated to C++. However, I've seen many libraries that do use exceptions, but
do not necessarily pass exception safety guarantees. I should know, because
I've written such libraries myself. When I started programming in C++, there
was no literature, such as Exceptional C++ or the special edition of TCPL,
that would have explained the issues satisfactorily.
> If there is a potential for an exception to be
> thrown, however, whether the code is legacy or not is irrelevant to
> me... it needs to be fixed.
I agree. However, usually there is considerable schedule pressure (and limited
funding), which means that it is often necessary to choose which issues to fix
now and which issues to fix later. Often the decisions not to rewrite a major
library, because it is not exception safe, is a valid decision.
Another point worth considering is that typically many faults appear so
infrequently that it is very difficult to find any corresponding defect. Since
exceptions can (increasingly often) be associated with such faults and
defects, it can make sense to make programs tolerant to exceptions. For
example, should a program detect an unexpected exception, which behavior would
- Terminate the program immediately.
- Let the user try to save any unsaved work (to a different filename) and then
terminate the program.
It is worth pointing out that this situation is not limited to legacy code. I
have yet to find a practical programming methodology that would guarantee 100%
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk