Re: boost.threads [was RE: [boost] Re: sockets /network programming Requirements]

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-08-07 14:03:20

----- Original Message -----
From: "Scott McCaskill" <scott_at_[hidden]>

> > > I'm writing a compiler, if I get any kind of error,
> > > I print a message and terminate.
> >
> > That's a reasonable model, but if I were going to do that there would be
> no
> > point in using an exception: I'd just print the message and call
exit(1).
> >
>
> Really?  That seems like a very big decision to make at such a low level.

I think we're actually on the same page ;-)
I don't usually code for the "print a message and exit" model because it's
inflexible. What happens when you find out later that you need to be able to
recover, or you need to run your code on some embedded system which doesn't
have separate processes which can be killed and restarted. If you write for
an EH/recovery model you can always hack it to do the "message + exit"
thing.

> > > There's something I can't lay my fingers on:
> > > EH is dynamic, and very 'loose': its very easy to forget
> > > to catch some exception you should have caught.
> >
> > Naw, almost every try ought to come with a catch(...) at the end.
> >
>
> If I saw code that did that, I would think that the intent was, "if an
> exception was thrown, and I don't know what kind of exception it is, I'm
not
> going to let any of my callers know about it."  Why would one want to do
> this (as a general rule)?

You're drawing the wrong conclusions.
Most catch(...) clauses will rethrow.
The few others are probably reporting the error to the user, logging, or
translating errors.

-Dave