From: terekhov (terekhov_at_[hidden])
Date: 2002-01-18 08:54:45
--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> ----- Original Message -----
> From: "terekhov" <terekhov_at_d...>
> > > > Yes, it should; but you should always re-"throw"
> > > > unless you're really sure you want to break the
> > > > entire world. I think that should ALWAYS be true
> > > > for an anonymous catch(...), though. If you don't
> > > > know what it is, you can't "finalize" the exception
> > > > recovery, and you need to just clean up your own
> > > > local context and let someone else further down
> > > > handle it.
> > >
> > > Sometimes there is nobody further down, as we've seen.
> > And process terminates and that is GOOD.
> Not really. Sometimes, for example at a 'C' API boundary, you
simply have to
> use catch(...) so you can prevent an exception from crashing your
> Tom Becker has already pointed that out.
Perhaps Tom Becker or you could clarify this issue a bit more...
(for slowly thinking people, such as me and a couple of my
> And, as I've pointed out, when
> well-used, the type of an exception doesn't tell you much about
> needed for recovery - only how to report the error
well, the program could also, for example, change its
further logic/processing, if something does not seem to
work but there is one or two "workarounds".
> - and there are some
> processes for which continuing to run is much more important than an
> accurate error report.
Perhaps we disagree on one rather simple thing - you seem
to say that exceptions should just carry some error messages
or so only. I think, however, that they have MEANING too;
bad_cast, for example, has REALLY BAD MEANING. Do
you really want such program run your bank account? Do
you know any program which should run just eating not
handled bad_casts from time to time?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk