Re: [boost] Re: Basic guarantee and synchronized multiple updates.

From: David Abrahams (dave_at_[hidden])
Date: 2002-09-28 11:45:43

From: "Alexander Terekhov" <terekhov_at_[hidden]>

> David Abrahams wrote:
> >
> > From: "Alexander Terekhov" <terekhov_at_[hidden]>
> >
> > I really wouldn't want std::logic_error in the first place, but if
someone
> > is so foolish as to throw one, there *will* be stack unwinding. That's
how
> > exceptions work (yeah, I know there are conditions under which you can
> > terminate without unwinding, but that's what assert/abort() is for).
>
> But there are really quite a few "corner cases" when the caller/user
> should have a right to decide whether this or that exception is meant
> for local recovery (will be caught) or should rather result in a nice
> core dump (at throw point) with recovery actions being done on some
> higher level. I'll try to give an example: on mainframes programmers
> are supposed to document address space size requirements (depending on
> the config/input/workload) for their programs. System programmers and
> operators use this information for capacity planning, etc. in order to
> achieve "reasonable" performance/throughput on their systems (or just
> buy "more hardware" ;-) ). They really don't want to see those dumb
> "out-of-memory" errors. Quite often, running out of memory just means
> that something was leaking/looping and/or the calculations were just
> wrong. In any event, our service folks really want to see a full dump,
> instead of kinda silly: "catch(const std::exception& e) { cerr <<
> e->what(); exit( EXIT_FAILURE ); }"-like stuff.

OK. Sounds like the sort of thing that could be implemented at the library
level, if only everyone would cooperate and use the facilities. Maybe we
need a Boost error-handling library. Sounds like with all these
nasty-C++-implementation-choices and thread cancellation safety issues, we
probably do.

> > I don't seem to care so much because most of my code isn't written with
> > thread safety in mind and doesn't have to run in multithreaded
contexts.
> > I'll worry about that when I have users who need it, knowledge of the
> > platforms I'm targeting, and an environment in which to test what I've
> > done.
>
> Fair enough. If/when you'll see PJP, please drop these links "on him":

I'll see him soon enough, but that's <ahem> "not my style". I don't bring
up issues with busy people unless I'm prepared to at least take the time to
explain what I'm talking about. "Dropping links on" people like me (and
probably PJP) is a sure way to get them to stop listening.

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com