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

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-08-07 11:23:25

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?

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

        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.

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

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

        Why not?

        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.
On the other hand an if/then/else style construction
seems more robust. In SML, you can use pattern matching
to ensure you catch _all_ the cases, 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),
but they don't work with templates. Why?

-- 
John (Max) Skaller, mailto:skaller_at_[hidden] 
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
New generation programming language Felix  http://felix.sourceforge.net
Literate Programming tool Interscript     
http://Interscript.sourceforge.net