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

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-08-07 11:49:51

----- Original Message -----
From: "John Max Skaller" <skaller_at_[hidden]>

> David Abrahams wrote:
>
> > Thanks for that ;-) I think you've mostly got the right idea. Obviously,
EH
> > doesn't work well as a replacement for break. I think it's a mistake to
try
> > to use it that way, no matter how much it looks like it's capable of
making
> > up for break's many deficiencies.
>
> I agree, but my question is 'Why?' Can you give a more
> abstract explanation?

For one thing, it's usually poorly optimized for things that are likely to
happen as often as you'll want to break from a loop. For another, it's a
whole lot of syntax to use just to reliably get out of a loop. And finally
there are my points you quote below about common recovery/cleanup actions.

> > > My initial experience with EH in C++ was that
> > > it greatly simplified code. More recently, however,
> > > I've been avoiding exceptions for anything other than
> > > catastrophic errors
> >
> > What do you mean by "catastrophic"?
>
> No recovery possible.
>
> 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).

Lots of compilers try to fix up the parse tree and continue so you can find
more errors(including C++ compilers, but C++ syntax makes that job
notoriously difficult).

> In a 'continuously running system' such as a Web client
> or server or real time controller, one obviously doesn't terminate
> the whole program, but do the moral equivalent: tear down
> the faulty sub-system and rebuild it. EG if you're executing
> some Javascript and get an error, abandon the whole script.

Some systems don't give you subsystem-wide resource recovery, so you need to
make sure all destructors run, etc., when the subsystem is torn down. For
those, an exception is a good way to leave the scope in which the subsystem
was created.

> > Yes. For a large class of operations (among them many strong-guarantee
> > operations), the recovery/cleanup actions needed are independent of the
> > source of the error or the reason for the error. For those cases, EH
makes
> > things much simpler.
>
> Ah. OK, that's an interesting viewpoint.
>
> > Conditions where an error can be locally recovered from such that the
> > enclosing operation may continue are rare in the programs I write.
>
> That's my general experience too. However, it doesn't
> quite answer the question: why not still use EH for alternate
> flow control?

The only arguments I can think of are based on efficiency and syntax. From
an abstract viewpoint, there's no problem.

> >Where they do occur, I have tended not to use EH to deal with it.
>
> Why not?

Lots of syntax, and there is a layer of abstraction introduced. As you say,
a simple if statement can be much clearer when the condition must be handled
precisely at the point where it is detected. OTOH, exceptions are OK at this
if pressed (e.g. if the operation throws instead of returning an error
code).

> 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.

> On the other hand an if/then/else style construction
> seems more robust.

Just as easy to avoid checking for a particular error code, no?

> In SML, you can use pattern matching
> to ensure you catch _all_ the cases,

That's spelled catch(...) in C++.

> so this kind of
> 'testing return codes' is more secure statically
> than in C++. In both languages, EH lacks that security.
> You only find out you mishandled a case during testing --
> if you're lucky.
>
> I'm waffling because I can't explain this tersely,
> because I don't really understand it fully. For example,
> Exception Specifications seem to provide static guarrantees
> (ignoring the fact that the checking isn't done until run time),

I think you hit the nail on the head. They "seem" to provide static
guarantees, if you ignore the facts. I think people would be better off
ignoring what they seem to provide and dealing with the facts.

> but they don't work with templates. Why?

Sure they do, just not very conveniently unless they're empty. But I have no
defense for most uses of exception-specifications, as many people know.

-Dave