Re: first sight

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 
caller.
> 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 
colleagues here)

> And, as I've pointed out, when
> well-used, the type of an exception doesn't tell you much about 
what's
> 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?

regards,
alexander.