I've moved the individual chunks of text around so this reads a little
better.

>> It actually sounds more like someone who has learned not to trust decisions made by someone far far away who doesn't have a clue what my code is intended to do or how it is intended to react.
> 
> It may do. Alternatively, it may sound like someone who knows what they're talking about, as I'm quite sure B Meyer and W Bright do, and I'm somewhat confident I do.
>

Right. Dig out your copy of Meyer and re-read it. Don't go referencing it again until you have. Chapter 7 deals with pre/post conditions and contracts and strangely enough it doesn't mention anywhere about a process throwing its hands in the air and terrminating itself because something didn't happen as expected. He's quite explicit about it - if anything fails for any reason it throws an exception, which should be caught and dealt with and the operation possibly retried. Apparently he's quite hot on this, there are a few Eiffel features built into the language for just this reason. He goes even further with this logic than I have advocated, and states that hardware detected errors can/should be caught and turned into software exceptions which are in turn caught and dealt with and the relevant operation retried. He even has names for the concept, which you might have read once but have obviously forgotten 'Robustness' and 'Software Fault Tolerance'. Having skimmed the chapter quickly I can't find anywhere were he suggests that termination is an option - certainly not an option taken out of the programmers hands and enforced because a library misbehaved.


>> Define an invalid state. Define how you decide its an invalid state. If your code decides that it has detected an invalid state how do you know that the invalid state is not actually in your invalid state detection code.
> 
> Simple. It either satisfies the contract or it doesn't. If it does, then it's within the purview of the function/class. If it doesn't, it's within the purview of the client code, and the only sensible recourse for the function/class is to fire its assertion. (Again, whatever "fire" is is immaterial to the argument.)
> 

Couldn't agree more, exceptions should certainly be thrown in failure situations. I was under the impression this argument was regarding whether 'someone' (not the programmer writing the code) should be empowered to enforce a process termination when particular exception types were encountered.

>> Invalid
>> states are not detectable internally by a process.
> 
> Utterly disagree. If you attempt to dereference a null pointer, I'm pretty sure the process (helped by the hardware) can tell you that its now in an invalid state. Please explain otherwise.
> 

Can we clarify definitions here because I get the impression we are talking at slightly cross purposes. I have referred to 'invalid state' as meaning that a process is in such a state that continuing correctly is simply not possible - you defined it as such earlier. The issue at hand is what constitutes an invalid state and how it is detected. Your example above is most definitely *not* an example of definitive invalid process state. Sure, 95% of programs written in D or whatever else should shut down at this point, but the other 5% of mission critical production systems should not be forced to terminate because someone, somewhere, somewhen decided on a blanket termination policy. You claim to quote Meyer - read chapter 7 again and his suggestions for using the EXTERNAL_EXCEPTIONS mechanism to turn null dereferences into software exceptions to be caught and worked around.

>> It's like asking someone
>> to evaluate objectively whether they are sane or not.
> 
> Perhaps. The analogy's too weak to prove that, however, since I might say "that's true" and mean it's supporting of my POV.
> 
>> And having detected this invalid state is the only response immediate and total shutdown.
> 
> The only response is to halt. The definition of halt depends on the circumstances, and can be pretty much anything that results in a timely termination of the process
>

Agreed. Where I disagree is D's ability to correctly detect an unrecoverable invalid state. Where I disagree is the decision to have D enforce termination in every circumstance.


>> Can I not isolate the problem?
> 
> No. You've put part/all your process in an invalid state. How do you come back from that?
> 

Re-read Meyer. Is that getting boring? I only emphasize you should do this because you are misleading others on this mailing list by mis-stating Meyer's thoughts on this. I *am* in a position to decide on just how recoverable my program state is.

>> Am I not considered bright
>> enough to be trusted to do that with my own code?
> 
> The question is disengenuous, and attempts to beguile.
> 
> 1. You are clearly bright enough to be writing quality software, as are most members of this NG - I'm not saying otherwise.

You've seen enough of my code to make that judgement? Maybe there's an inverse square law in operation here. You check out my 10 - 15 lines code on the forum and decide I'm a quality programmer. You read thousands of Meyers words of wisdom and decide... well, what did you decide? To forget it all?

> 2. I'm not talking about "your own code", per se. Consider you're using some other library. If you violate its contract, how is it expected to behave? Should it spawn a subroutine that initiates an SMS conversation with its original author, who can interpret what you meant, rather than what you said?
> 

If the code is DbC then I expect to behave according to its contract. If that contract is sufficiently well defined to allow me to be confident of retrying with different data sets then I damn well want to retry. D should *not* have carte blanche to pull my plug! A library written to DbC standards should support retries especially well!


>> Is a failsafe mode not an
>> option?
> 
> No. If a given library needs to cater for a wide range of conditions, some of which are erroneous, then that's part of its contract.

Repetition begins to grind me down... Meyer, meyer, meyer... Chapter 7. Fault tolerance... gasp!

>> eg. After 2 years of intensive testing in which time no errors were detected the nuclear power plant went operational: unfortunately the software detected an invalid state and killed itself, taking out a two mile section of <insert favourite country>. Yes, it would have been nice if it would have shutown the reactor first, but hey, XYZ decided 5 years ago that we shouldn't do that.
> 
> This is just rot.
> 
> (btw, can I insert a couple of countries that I _don't_ like? <g>)
> 
The particular instance may be rot because as stated previously, D would never be allowed near a critical system given the current termination policy.


>> I could ramble on for ages but I have a feeling that this going to be one of those tin-hat thingies with barrages going back and forth for years. So I'll save me ammo up for later :)
> 
> You can ramble as much as you like. You won't change my opinion, nor that of the many esteemed engineers who ascribe to DbC. (One of which invented D, and writes our compiler.)
> 
DbC has nothing to do with arbitrary program termination. I quite like DbC. I have nothing against it all and would love to come across more code written like this. Shall I say it again for effect? DbC is wonderful and luvverly and the best thing since sliced bread. Please don't pervert its meaning to your dastardly ends.

>> And I'll contradict myself slightly here as well. I do consider that *some* invalid states may be detectable in *some* extremely limited situations but that the effort required to detect them far outweighs the benefits and false positives will be an issue. And having detected them I'll still be pissed if the damn process terminates itself!
> 
> Let me ask you to address your notions to a very simple case: strcpy().
> 
> Bear in mind that strcpy's signature is
> 
>     char *strcpy(char *dest, char const *src);
> 
> and that it always returns dest.
> 
> What should strcpy do if its passed a null pointer for its source string?
It should cause a SIGSEGV (*nix - sorry).
> What about a null pointer for its destination string?
It should cause a SIGSEGV (again *nix - don't ask me how windows deals with
it)
> How should it indicate error?
See above. I presume those are the errors you are talking about.
> How should client code of strcpy() detect, and react to, errors?
Joe Bloggs program to count sheep jumping over fences: let the OS core the
process and terminate the app. Note: D doesn't have anything to do with
this either.
My program monitoring the heart defibrillator (not that that's what I do):
Intercept (by whatever means are supported) the signal. Turn it into an
exception to throw to the caller. Caller (however many levels up the stack
- I don't expect whatever is calling strcpy to be in a position to do much
intelligent recovery) catches the exception and does whatever it has been
programmed to do. This could include:
 1) Try the next string in the vector.
 2) Decide that the message being processed was invalid. Dump it to log and
try the next message.
 3) lots of other Robust responses. Meyer. Chapter 7.
 4) Decide that the stack frame of the current thread must have been
corrupted somehow. Terminate the thread. Continue the process.
 5) Decide that the process heap is corrupt. Terminate the process.

Recap:
a) We agree (I think) on what an invalid state is.
b) We disagree on the point at which an invalid state can be detected. You
are talking in terms of recoverable exceptions whenever you give examples
of process terminating invalid states.
c) As a consequence of b) you are advocating brittle termination of possibly
perfectly viable processes. The point being that no-one except the person
programming it can know in advance when it has become invalid.
d) Don't terminate my process because it does stuff you don't like. I'm a
big boy now I can handle it.
d) Aaaaaarrrrgghhhhh. Read Meyer. Think Robustness - not brittle response.

Hmm. That's not good. It might be that I think I'm quoting Meyer, and I'm quoting someone else instead. For that, apologies to BM (and NG digesters), and I shall do as you say and certainly plough the bookshelf rather than my memory henceforth. It's been a long time since I read it, and I've digested several other things on this issue since, so may well have mixed them in an insane mental stew.

This potential misquoting aside, I don't resile from my position. If something's recoverable, then it's an exception. If it's not, then it's a fault. A fault puts a program into an invalid state, so continuation is, by definition, undefined. Your post doesn't effectively address that point. Even for the very simple and accessible example of strcpy() you've failed to provide a convincing treatment. You say you'd carry on somehow, offering five options. If I may, I'll heap derision on them now, since we're in engaging in robust debate.

>  1) Try the next string in the vector.

Will the rest of your program logic consider that the "null" string has been handled correctly? If so, you're program now has an invalid state, and *anything* might happen henceforth.

Alternatively, if you are writing code that handles this, then how is that being effected? If you are catching the null pointer before passing to strcpy, then this does not relate to DbC or strcpy; indeed, you've respected strcpy()'s contract in that case! <g> If you're catching the hardware null pointer exception then your code is abusing the semantics of a standard library function, being probably very inefficient, is anything but discoverable to maintainers, and not even portable (since not all hardwares provide null-pointer detection). In short, it's not good.

>  2) Decide that the message being processed was invalid. Dump it to log
and
> try the next message.

Dump what to log? The null, or a record of the null?

I'm really not sure what you mean here, so can't offer a rejoinder.

>  3) lots of other Robust responses. Meyer. Chapter 7.

Handwaving. Make a point, or don't. (Of course, I may have been doing this same tactic in this discussion. <g>)

>  4) Decide that the stack frame of the current thread must have been
> corrupted somehow. Terminate the thread. Continue the process.

This is *absolutely untenable*!! I defy you to provide a single creditable source that suggests that termination of a thread can leave a process in a valid state such that it can continue to live (beyond some non-trivial amount of final shutdown processing). This is a particularly pernicious myth that abounds in multi-threading, usually, if I might be so rude, by those who little understand multi-threading. Operating systems associate system objects with processes, and not with threads, so the opportunities for ending up in invalid states - locked handles, abandoned synchronisation objects, etc etc - are myriad in such a circumstance. Only the termination of the process can result in an orderly release of system resources.

>  5) Decide that the process heap is corrupt. Terminate the process.

Now we're talking! I like this one.


One general point I'd like to make: It seems that you're painting my argument as "I like process termination, and I don't give a fig about the consequences to users as long as I can adhere to my DbC purity". But that's not grokking the advantage that DbC confers. It's quite the opposite in fact, and it requires a mental leap to see the twist: By requiring early and severe failure, programs become _massively_ more robust.

For example, I worked on a stock-exchange data caching and delivery component in 1998, which is running inside what was, and still is, the busiest transactional website in the southern hemisphere. In six years of execution, my components have processed 100s of millions of transactions (involving on God knows how many billions of dollars), and have experienced 0 failures. Not a single one. And it's not that there's some desperate "handling" of faults in there, taking any extreme measure to keep processing. It's just that there are no faults. That's what DbC can give.



"Cabal" <cabalN05P4M@myrealbox.com> wrote in message news:cd5kuh$1t7u$1@digitaldaemon.com...
> I've moved the individual chunks of text around so this reads a little better.
>
> >> It actually sounds more like someone who has learned not to trust decisions made by someone far far away who doesn't have a clue what my code is intended to do or how it is intended to react.
> >
> > It may do. Alternatively, it may sound like someone who knows what
they're
> > talking about, as I'm quite sure B Meyer and W Bright do, and I'm
somewhat
> > confident I do.
> >
>
> Right. Dig out your copy of Meyer and re-read it. Don't go referencing it again until you have. Chapter 7 deals with pre/post conditions and contracts and strangely enough it doesn't mention anywhere about a process throwing its hands in the air and terrminating itself because something didn't happen as expected. He's quite explicit about it - if anything
fails
> for any reason it throws an exception, which should be caught and dealt with and the operation possibly retried. Apparently he's quite hot on
this,
> there are a few Eiffel features built into the language for just this reason. He goes even further with this logic than I have advocated, and states that hardware detected errors can/should be caught and turned into software exceptions which are in turn caught and dealt with and the relevant operation retried. He even has names for the concept, which you might have read once but have obviously forgotten 'Robustness' and 'Software Fault Tolerance'. Having skimmed the chapter quickly I can't
find
> anywhere were he suggests that termination is an option - certainly not an option taken out of the programmers hands and enforced because a library misbehaved.
>
>
> >> Define an invalid state. Define how you decide its an invalid state. If your code decides that it has detected an invalid state how do you know that the invalid state is not actually in your invalid state detection code.
> >
> > Simple. It either satisfies the contract or it doesn't. If it does, then it's within the purview of the function/class. If it doesn't, it's
within
> > the purview of the client code, and the only sensible recourse for the function/class is to fire its assertion. (Again, whatever "fire" is is immaterial to the argument.)
> >
>
> Couldn't agree more, exceptions should certainly be thrown in failure situations. I was under the impression this argument was regarding whether 'someone' (not the programmer writing the code) should be empowered to enforce a process termination when particular exception types were encountered.
>
> >> Invalid
> >> states are not detectable internally by a process.
> >
> > Utterly disagree. If you attempt to dereference a null pointer, I'm
pretty
> > sure the process (helped by the hardware) can tell you that its now in
an
> > invalid state. Please explain otherwise.
> >
>
> Can we clarify definitions here because I get the impression we are
talking
> at slightly cross purposes. I have referred to 'invalid state' as meaning that a process is in such a state that continuing correctly is simply not possible - you defined it as such earlier. The issue at hand is what constitutes an invalid state and how it is detected. Your example above is most definitely *not* an example of definitive invalid process state.
Sure,
> 95% of programs written in D or whatever else should shut down at this point, but the other 5% of mission critical production systems should not be forced to terminate because someone, somewhere, somewhen decided on a blanket termination policy. You claim to quote Meyer - read chapter 7
again
> and his suggestions for using the EXTERNAL_EXCEPTIONS mechanism to turn null dereferences into software exceptions to be caught and worked around.
>
> >> It's like asking someone
> >> to evaluate objectively whether they are sane or not.
> >
> > Perhaps. The analogy's too weak to prove that, however, since I might
say
> > "that's true" and mean it's supporting of my POV.
> >
> >> And having detected this invalid state is the only response immediate
and
> >> total shutdown.
> >
> > The only response is to halt. The definition of halt depends on the circumstances, and can be pretty much anything that results in a timely termination of the process
> >
>
> Agreed. Where I disagree is D's ability to correctly detect an
unrecoverable
> invalid state. Where I disagree is the decision to have D enforce termination in every circumstance.
>
>
> >> Can I not isolate the problem?
> >
> > No. You've put part/all your process in an invalid state. How do you
come
> > back from that?
> >
>
> Re-read Meyer. Is that getting boring? I only emphasize you should do this because you are misleading others on this mailing list by mis-stating Meyer's thoughts on this. I *am* in a position to decide on just how recoverable my program state is.
>
> >> Am I not considered bright
> >> enough to be trusted to do that with my own code?
> >
> > The question is disengenuous, and attempts to beguile.
> >
> > 1. You are clearly bright enough to be writing quality software, as are most members of this NG - I'm not saying otherwise.
>
> You've seen enough of my code to make that judgement? Maybe there's an inverse square law in operation here. You check out my 10 - 15 lines code on the forum and decide I'm a quality programmer. You read thousands of Meyers words of wisdom and decide... well, what did you decide? To forget it all?
>
> > 2. I'm not talking about "your own code", per se. Consider you're using some other library. If you violate its contract, how is it expected to behave? Should it spawn a subroutine that initiates an SMS conversation with its original author, who can interpret what you meant, rather than what you said?
> >
>
> If the code is DbC then I expect to behave according to its contract. If that contract is sufficiently well defined to allow me to be confident of retrying with different data sets then I damn well want to retry. D should *not* have carte blanche to pull my plug! A library written to DbC standards should support retries especially well!
>
>
> >> Is a failsafe mode not an
> >> option?
> >
> > No. If a given library needs to cater for a wide range of conditions,
some
> > of which are erroneous, then that's part of its contract.
>
> Repetition begins to grind me down... Meyer, meyer, meyer... Chapter 7. Fault tolerance... gasp!
>
> >> eg. After 2 years of intensive testing in which time no errors were detected the nuclear power plant went operational: unfortunately the software detected an invalid state and killed itself, taking out a two mile section of <insert favourite country>. Yes, it would have been
nice
> >> if it would have shutown the reactor first, but hey, XYZ decided 5
years
> >> ago that we shouldn't do that.
> >
> > This is just rot.
> >
> > (btw, can I insert a couple of countries that I _don't_ like? <g>)
> >
> The particular instance may be rot because as stated previously, D would never be allowed near a critical system given the current termination policy.
>
>
> >> I could ramble on for ages but I have a feeling that this going to be
one
> >> of those tin-hat thingies with barrages going back and forth for years. So I'll save me ammo up for later :)
> >
> > You can ramble as much as you like. You won't change my opinion, nor
that
> > of the many esteemed engineers who ascribe to DbC. (One of which
invented
> > D, and writes our compiler.)
> >
> DbC has nothing to do with arbitrary program termination. I quite like
DbC.
> I have nothing against it all and would love to come across more code written like this. Shall I say it again for effect? DbC is wonderful and luvverly and the best thing since sliced bread. Please don't pervert its meaning to your dastardly ends.
>
> >> And I'll contradict myself slightly here as well. I do consider that *some* invalid states may be detectable in *some* extremely limited situations but that the effort required to detect them far outweighs
the
> >> benefits and false positives will be an issue. And having detected them I'll still be pissed if the damn process terminates itself!
> >
> > Let me ask you to address your notions to a very simple case: strcpy().
> >
> > Bear in mind that strcpy's signature is
> >
> >     char *strcpy(char *dest, char const *src);
> >
> > and that it always returns dest.
> >
> > What should strcpy do if its passed a null pointer for its source
string?
> It should cause a SIGSEGV (*nix - sorry).
> > What about a null pointer for its destination string?
> It should cause a SIGSEGV (again *nix - don't ask me how windows deals
with
> it)
> > How should it indicate error?
> See above. I presume those are the errors you are talking about.
> > How should client code of strcpy() detect, and react to, errors?
> Joe Bloggs program to count sheep jumping over fences: let the OS core the
> process and terminate the app. Note: D doesn't have anything to do with
> this either.
> My program monitoring the heart defibrillator (not that that's what I do):
> Intercept (by whatever means are supported) the signal. Turn it into an
> exception to throw to the caller. Caller (however many levels up the stack
> - I don't expect whatever is calling strcpy to be in a position to do much
> intelligent recovery) catches the exception and does whatever it has been
> programmed to do. This could include:
>  1) Try the next string in the vector.
>  2) Decide that the message being processed was invalid. Dump it to log
and
> try the next message.
>  3) lots of other Robust responses. Meyer. Chapter 7.
>  4) Decide that the stack frame of the current thread must have been
> corrupted somehow. Terminate the thread. Continue the process.
>  5) Decide that the process heap is corrupt. Terminate the process.
>
> Recap:
> a) We agree (I think) on what an invalid state is.
> b) We disagree on the point at which an invalid state can be detected. You
> are talking in terms of recoverable exceptions whenever you give examples
> of process terminating invalid states.
> c) As a consequence of b) you are advocating brittle termination of
possibly
> perfectly viable processes. The point being that no-one except the person
> programming it can know in advance when it has become invalid.
> d) Don't terminate my process because it does stuff you don't like. I'm a
> big boy now I can handle it.
> d) Aaaaaarrrrgghhhhh. Read Meyer. Think Robustness - not brittle response.
>
>

> Hmm. That's not good. It might be that I think I'm quoting Meyer, and I'm quoting someone else instead. For that, apologies to BM (and NG digesters), and I shall do as you say and certainly plough the bookshelf rather than my memory henceforth. It's been a long time since I read it, and I've digested several other things on this issue since, so may well have mixed them in an insane mental stew.

> This potential misquoting aside, I don't resile from my position. If something's recoverable, then it's an exception. If it's not, then it's a fault. A fault puts a program into an invalid state, so continuation is, by definition, undefined. Your post doesn't effectively address that point. Even for the very simple and accessible example of strcpy() you've failed to provide a convincing treatment. You say you'd carry on somehow, offering five options. If I may, I'll heap derision on them now, since we're in engaging in robust debate.
> 

Christ! I pull your crutch out from under you and you still insist on limping on :)

>>  1) Try the next string in the vector.
> 
> Will the rest of your program logic consider that the "null" string has been handled correctly? If so, you're program now has an invalid state, and *anything* might happen henceforth.
> 
> Alternatively, if you are writing code that handles this, then how is that being effected? If you are catching the null pointer before passing to strcpy, then this does not relate to DbC or strcpy; indeed, you've respected strcpy()'s contract in that case! <g> If you're catching the hardware null pointer exception then your code is abusing the semantics of a standard library function, being probably very inefficient, is anything but discoverable to maintainers, and not even portable (since not all hardwares provide null-pointer detection). In short, it's not good.
> 

The example given reflected the suggestions in Meyer (not the individual recovery options - just the fact that there could be recovery of some sort). As he was your main argumentative prop I found it appropriate to take his suggestion and beat you with it. I can't say I have ever found cause or desire to catch a hardware signal nor do I intend finding myself in a situation where it is necessary. Don't try and read too much into it.

>>  2) Decide that the message being processed was invalid. Dump it to log
> and
>> try the next message.
> 
> Dump what to log? The null, or a record of the null?
> I'm really not sure what you mean here, so can't offer a rejoinder.

Apologies. In my head I was thinking along the lines of strcpy'ing a field from a message. I'll be more clear next time.


>>  3) lots of other Robust responses. Meyer. Chapter 7.
> 
> Handwaving. Make a point, or don't. (Of course, I may have been doing this same tactic in this discussion. <g>)

Not just hand waving. I had a rubber chicken in each hand and was running around the room making gibbon noises. Think impact!

>>  4) Decide that the stack frame of the current thread must have been
>> corrupted somehow. Terminate the thread. Continue the process.
> 
> This is *absolutely untenable*!! I defy you to provide a single creditable source that suggests that termination of a thread can leave a process in a valid state such that it can continue to live (beyond some non-trivial amount of final shutdown processing). This is a particularly pernicious myth that abounds in multi-threading, usually, if I might be so rude, by those who little understand multi-threading. Operating systems associate system objects with processes, and not with threads, so the opportunities for ending up in invalid states - locked handles, abandoned synchronisation objects, etc etc - are myriad in such a circumstance. Only the termination of the process can result in an orderly release of system resources.
> 

I have an object on the stack of my thread (or in a TLS variable - take your
pick). This object has been initialised by reading a stream of data. I
perform a strcpy on it and intercept a null ptr exception generated by the
call. This null ptr and the object holding it are totally and utterly
isolated from the rest of the process. I can too make my own mind up about
whether I can terminate this thread.
Also, before assuming you know everything about threads and threading issues
I suggest you brush up on more than just Windows threads. I am aware (now
that I try to remember) that windows has a particularly broken attitude to
thread termination. Being a *nix guy I was implying the pthreads behaviour
model where thread cancellation with stack rewinding is preferred if you
want your program to continue nicely - and many programs do cancel
individual threads and continue to run perfectly well.


>>  5) Decide that the process heap is corrupt. Terminate the process.
> 
> Now we're talking! I like this one.
> 
> 
> One general point I'd like to make: It seems that you're painting my argument as "I like process termination, and I don't give a fig about the consequences to users as long as I can adhere to my DbC purity". But that's not grokking the advantage that DbC confers. It's quite the opposite in fact, and it requires a mental leap to see the twist: By requiring early and severe failure, programs become _massively_ more robust.
> 
> For example, I worked on a stock-exchange data caching and delivery component in 1998, which is running inside what was, and still is, the busiest transactional website in the southern hemisphere. In six years of execution, my components have processed 100s of millions of transactions (involving on God knows how many billions of dollars), and have experienced 0 failures. Not a single one. And it's not that there's some desperate "handling" of faults in there, taking any extreme measure to keep processing. It's just that there are no faults. That's what DbC can give.
> 
Again, I find myself agreeing with bits of what you say. Yes, it is an known feature programmed into many robust 'systems' (not programs - no single program becomes more robust by being killed) that individual components should fail early and noisily. Every single program I have written or being involved with writing for the last twelve years has had this 'feature'. The key point is that this was chosen as the way to do it. At any point we could have said "No! We'll catch X or Y and attempt to recover in this particular instance or that particular instance." There would never have been a little voice in the pits of the library saying "Oooo no! you can't do that. You've got to die!". Also, you seem to imbuing DbC with magical properties to prevent failures (probably not your explicit intent but it could be read that way by the uninformed). DbC specifies pre/post conditions and invariants and exceptions on violation of these - nowhere is it implicit or explicit that the only option is to terminate the program. That is a choice for the programmer.

The crux of this argument is choice. You advocate enforced process termination in all cases irrelevant of the merits in individual cases for recovery.  It appears to me that you have ideas about what can be done in a process and that these set ideas are limited to your experience (probably on windows given the tirade above regarding thread termination and the windows assumptions built into it). My experience is with *nix where we can, if we choose, implement various recovery procedures safely and have a process continue after a 'failure' (your failure, my exception). Please don't mistake what you consider to be 'the one true way' with the actuality of the rest of the world at large.

I'll say it again - in another way. Please don't make the mistake of forcing me to conform to what you consider to be the only way to do things. Just because early termination can be a good thing does not make it the only thing possible.

"Cabal" <cabalN05P4M@myrealbox.com> wrote in message news:cd6651$25ur$1@digitaldaemon.com...
> > Hmm. That's not good. It might be that I think I'm quoting Meyer, and I'm quoting someone else instead. For that, apologies to BM (and NG digesters), and I shall do as you say and certainly plough the bookshelf rather than my memory henceforth. It's been a long time since I read it, and I've digested several other things on this issue since, so may well have mixed them in an insane mental stew.
>
> > This potential misquoting aside, I don't resile from my position. If something's recoverable, then it's an exception. If it's not, then it's a fault. A fault puts a program into an invalid state, so continuation is, by definition, undefined. Your post doesn't effectively address that point. Even for the very simple and accessible example of strcpy() you've failed to provide a convincing treatment. You say you'd carry on somehow, offering five options. If I may, I'll heap derision on them now, since we're in engaging in robust debate.
> >
>
> Christ! I pull your crutch out from under you and you still insist on limping on :)
>
> >>  1) Try the next string in the vector.
> >
> > Will the rest of your program logic consider that the "null" string has been handled correctly? If so, you're program now has an invalid state, and *anything* might happen henceforth.
> >
> > Alternatively, if you are writing code that handles this, then how is that being effected? If you are catching the null pointer before passing to strcpy, then this does not relate to DbC or strcpy; indeed, you've respected strcpy()'s contract in that case! <g> If you're catching the hardware null pointer exception then your code is abusing the semantics of a standard library function, being probably very inefficient, is anything but discoverable to maintainers, and not even portable (since not all hardwares provide null-pointer detection). In short, it's not good.
> >
>
> The example given reflected the suggestions in Meyer (not the individual recovery options - just the fact that there could be recovery of some sort). As he was your main argumentative prop I found it appropriate to take his suggestion and beat you with it. I can't say I have ever found cause or desire to catch a hardware signal nor do I intend finding myself in a situation where it is necessary. Don't try and read too much into it.

I don't get the purpose of this paragraph. Is it just a sufficient quantity of words to mask the fact that you won't, or can't, address the simple example of strcpy()?

> >>  2) Decide that the message being processed was invalid. Dump it to log
> > and
> >> try the next message.
> >
> > Dump what to log? The null, or a record of the null?
> > I'm really not sure what you mean here, so can't offer a rejoinder.
>
> Apologies. In my head I was thinking along the lines of strcpy'ing a field from a message. I'll be more clear next time.
>
>
> >>  3) lots of other Robust responses. Meyer. Chapter 7.
> >
> > Handwaving. Make a point, or don't. (Of course, I may have been doing this same tactic in this discussion. <g>)
>
> Not just hand waving. I had a rubber chicken in each hand and was running around the room making gibbon noises. Think impact!
>
> >>  4) Decide that the stack frame of the current thread must have been
> >> corrupted somehow. Terminate the thread. Continue the process.
> >
> > This is *absolutely untenable*!! I defy you to provide a single creditable source that suggests that termination of a thread can leave a process in a valid state such that it can continue to live (beyond some non-trivial amount of final shutdown processing). This is a particularly pernicious myth that abounds in multi-threading, usually, if I might be so rude, by those who little understand multi-threading. Operating systems associate system objects with processes, and not with threads, so the opportunities for ending up in invalid states - locked handles, abandoned synchronisation objects, etc etc - are myriad in such a circumstance. Only the termination of the process can result in an orderly release of system resources.
> >
>
> I have an object on the stack of my thread (or in a TLS variable - take your
> pick). This object has been initialised by reading a stream of data. I
> perform a strcpy on it and intercept a null ptr exception generated by the
> call. This null ptr and the object holding it are totally and utterly
> isolated from the rest of the process. I can too make my own mind up about
> whether I can terminate this thread.
> Also, before assuming you know everything about threads and threading issues
> I suggest you brush up on more than just Windows threads.

Not sure if you're using "you" to mean me, or to mean "one". If you mean me, I certainly don't think I know everything about threading on either Win32 or UNIX, any more than I think I know everythng about anything. Only an idiot does that. But I have experience building very robust systems with both Win32 threads and PThreads.

Before we steam ahead on this, maybe when you said "Terminate the thread" you meant, have the the thread exit / return. If that's the case (i) we're violently agreeing, and (ii) you should have said what you meant. If you do indeed mean terminate - i.e. to halt the thread, remove it from the scheduler and discard its memory - then I stand by my comments.

> I am aware (now
> that I try to remember) that windows has a particularly broken attitude to
> thread termination. Being a *nix guy I was implying the pthreads behaviour
> model where thread cancellation with stack rewinding is preferred if you
> want your program to continue nicely - and many programs do cancel
> individual threads and continue to run perfectly well.

And this does indeed seem to indicate you meant exit, or return from. In which case you should have spoken precisely, and saved us both some time.

> >>  5) Decide that the process heap is corrupt. Terminate the process.
> >
> > Now we're talking! I like this one.
> >
> >
> > One general point I'd like to make: It seems that you're painting my argument as "I like process termination, and I don't give a fig about the consequences to users as long as I can adhere to my DbC purity". But that's not grokking the advantage that DbC confers. It's quite the opposite in fact, and it requires a mental leap to see the twist: By requiring early and severe failure, programs become _massively_ more robust.
> >
> > For example, I worked on a stock-exchange data caching and delivery component in 1998, which is running inside what was, and still is, the busiest transactional website in the southern hemisphere. In six years of execution, my components have processed 100s of millions of transactions (involving on God knows how many billions of dollars), and have experienced 0 failures. Not a single one. And it's not that there's some desperate "handling" of faults in there, taking any extreme measure to keep processing. It's just that there are no faults. That's what DbC can give.
> >
> Again, I find myself agreeing with bits of what you say. Yes, it is an known feature programmed into many robust 'systems' (not programs - no single program becomes more robust by being killed) that individual components should fail early and noisily. Every single program I have written or being involved with writing for the last twelve years has had this 'feature'. The key point is that this was chosen as the way to do it. At any point we could have said "No! We'll catch X or Y and attempt to recover in this particular instance or that particular instance." There would never have been a little voice in the pits of the library saying "Oooo no! you can't do that. You've got to die!". Also, you seem to imbuing DbC with magical properties to prevent failures (probably not your explicit intent but it could be read that way by the uninformed). DbC specifies pre/post conditions and invariants and exceptions on violation of these - nowhere is it implicit or explicit that the only option is to terminate the program. That is a choice for the programmer.
>
> The crux of this argument is choice. You advocate enforced process termination in all cases irrelevant of the merits in individual cases for recovery.  It appears to me that you have ideas about what can be done in a process and that these set ideas are limited to your experience (probably on windows given the tirade above regarding thread termination and the windows assumptions built into it). My experience is with *nix where we can, if we choose, implement various recovery procedures safely and have a process continue after a 'failure' (your failure, my exception).

Man, how many times do I have to say it: if it's recoverable, it's an exception. If it's not, it's an error (or fault, for a less ambiguous term). You keep implying that I'm stipulating that a process should fail from a recoverable error. I am not.

> Please
> don't mistake what you consider to be 'the one true way' with the actuality
> of the rest of the world at large.
>
> I'll say it again - in another way. Please don't make the mistake of forcing me to conform to what you consider to be the only way to do things. Just because early termination can be a good thing does not make it the only thing possible.

I simply remain a blank page, waiting for someone to write in it how a process can validly proceed once it has been rendered in an invalid (or undefined) state. Please scribble away in something legible.

Since we're casting aspersions about each others knowledge / POVs on scant evidence, I shall comment that to me it seems you still don't "get" the whole enforcement thing. By early enforcement of failure, one avoids failure. That, along with the undefined behaviour of faulted processes, are the two sides of my argument. But we seem to be failing to connect in either regard, and I can't think of any other ways to say them, so I'll shut my trap.

:)

Okay. Clean slate (apart from mutterings about obtuse pedantic buggers)

These are the points argued so far:

1)
You: When a hardware exception occurs your process is by definition in an
invalid state and must exit rather swiftly. No ifs, no buts, no reprieve.
Me: Not the case. Zero page accesses, divide by 0 can be recovered from.
2)
You: DbC violations are unrecoverable. You process is by definition in an
invalid state and must exit rather swiftly. etc etc.
Me: Not the case. blah blah.

If I have mis-represented you please correct me.

Everything else appears to be rehashing the above one way or another or impuning the others knowledge or ability. And all because there is a mis-feature in D which states that Error and it's derivatives are non-recoverable. You don't question the validity of that assumption - I do. It's that simple and everything in this thread follows logically on both sides of the argument.

Please take note that all along I have acknowledged that my 'examples' are contrived and I haven't found need or desire to implement them, they were given in response to the examples for non-recoverability you presented to make your case. They exist purely for the sake of demonstrating that process termination is not the one and only option and should not be foisted on everyone just because it's the desirable default option in most cases.

And do none of you morbid buggers reading this thread know anything about template specialisations and why alias's screw them up? If you do I'd appreciate you looking at the thread "Template specialisations and 'alias'". Move along now. Nothing to see here. :)

Thx

"Cabal" <cabalN05P4M@myrealbox.com> wrote in message news:cd6arm$2803$1@digitaldaemon.com...
> Okay. Clean slate (apart from mutterings about obtuse pedantic buggers)
>
> These are the points argued so far:
>
> 1)
> You: When a hardware exception occurs your process is by definition in an
> invalid state and must exit rather swiftly. No ifs, no buts, no reprieve.

Didn't say hardware exceptions. (Or if I did, I didn't necessarily mean it).

Indexing off the end of an array would also put the program into an invalid state, but would be unlikely to result in hardware exception (except where it's snug against an uncommitted page).

> Me: Not the case. Zero page accesses, divide by 0 can be recovered from.
> 2)
> You: DbC violations are unrecoverable. You process is by definition in an
> invalid state and must exit rather swiftly. etc etc.
> Me: Not the case. blah blah.

Correct

>
> If I have mis-represented you please correct me.
>
> Everything else appears to be rehashing the above one way or another or impuning the others knowledge or ability. And all because there is a mis-feature in D which states that Error and it's derivatives are non-recoverable. You don't question the validity of that assumption - I
do.

I don't think you're right here. I've not developed my opinions on this issue because of some little-visited comment in object.d. Is that what you're implying? (I'd have to have had a time machine, for a kick off!)

> It's that simple and everything in this thread follows logically on both sides of the argument.
>
> Please take note that all along I have acknowledged that my 'examples' are contrived and I haven't found need or desire to implement them, they were given in response to the examples for non-recoverability you presented to make your case. They exist purely for the sake of demonstrating that process termination is not the one and only option and should not be foisted on everyone just because it's the desirable default option in most cases.

As was discussed a short while ago, the nuclear reactor example is the perfect example of what I'm talking about. If you're still interested in this debate, please respond to that argument, since I can't imagine being able to come up with a more convincing example.

"Cabal" <cabalN05P4M@myrealbox.com> wrote in message news:cd6b0k$2803$2@digitaldaemon.com...
> And do none of you morbid buggers reading this thread know anything about template specialisations and why alias's screw them up? If you do I'd appreciate you looking at the thread "Template specialisations and 'alias'". Move along now. Nothing to see here. :)

See my various posts on the NG about using the "hack" technique to get the alias'd types.

He he, nice to be on the same team for a mo, is it not? :-)

Once more unto the breach dear friends....

>> These are the points argued so far:
>>
>> 1)
>> You: When a hardware exception occurs your process is by definition in an
>> invalid state and must exit rather swiftly. No ifs, no buts, no reprieve.
> 
> Didn't say hardware exceptions. (Or if I did, I didn't necessarily mean
> it).

Apologies for assuming more knowledge on your behalf than you had - when someone talks about the behaviour expected from passing null's to strcpy I automatically assume they have an inkling that they are going to get hardware exceptions/faults.

> Indexing off the end of an array would also put the program into an invalid state, but would be unlikely to result in hardware exception (except where it's snug against an uncommitted page).

Core paradigm mismatch alert! Hello we meet again. Regardless of hardware exceptions, accessing [I'll presume read as it fits my part of the argument and you seem to be talking about any access) beyond the range of an array does *not* put anything anywhere, least of all a process into an invalid state. It implies that something somewhere has used an inappropriate value - nothing more. It's entirely possible to continue execution - there is nothing intrinsically invalidating about such accesses. Am I repeating myself?

>> Me: Not the case. Zero page accesses, divide by 0 can be recovered from.
>> 2)
>> You: DbC violations are unrecoverable. You process is by definition in an
>> invalid state and must exit rather swiftly. etc etc.
>> Me: Not the case. blah blah.
> 
> Correct

Me: No its not!
You: Yes it is!
Me: No its not!
You: He's behind you!

Panto season might well be here before this one is resolved.

>>
>> If I have mis-represented you please correct me.
>>
>> Everything else appears to be rehashing the above one way or another or impuning the others knowledge or ability. And all because there is a mis-feature in D which states that Error and it's derivatives are non-recoverable. You don't question the validity of that assumption - I
> do.
> 
> I don't think you're right here. I've not developed my opinions on this issue because of some little-visited comment in object.d. Is that what you're implying? (I'd have to have had a time machine, for a kick off!)

I can't even be bothered to go look at object.d now that you've told me
there's a comment in there. I'm working entirely off your comments in the
thread above. You started this thread with concerns about which exception
conditions were Exception derived and which were Error derived. Not the
fact that Exceptions were catchable and Error supposedly not.
  <Quote>(Remember, Error is non-recoverable.)</Quote>
I certainly based my commentary on this statement and what you've said
since. I think that your arguments are entirely logical and well thought
out/through if we assume your basic premise is correct. Unfortunately you
are wrong down at the very bottom of your pile of building blocks.

> 
>> It's that simple and everything in this thread follows logically on both sides of the argument.
>>
>> Please take note that all along I have acknowledged that my 'examples' are contrived and I haven't found need or desire to implement them, they were given in response to the examples for non-recoverability you presented to make your case. They exist purely for the sake of demonstrating that process termination is not the one and only option and should not be foisted on everyone just because it's the desirable default option in most cases.
> 
> As was discussed a short while ago, the nuclear reactor example is the perfect example of what I'm talking about. If you're still interested in this debate, please respond to that argument, since I can't imagine being able to come up with a more convincing example.

My keyboard appears to be getting clogged up with all the hair I'm pulling out here! How many large and small scale examples do you need? Yes, they are all contrived. Acknowledged at the point of contrivance. I am not trying to present real world cases - I am trying to make sure that you realise that there could be cases out there in the real world which do not match your nice, tidy and limited development world view. You are trying to constrain D to your particular requirements. Stop it!

btw - you do realise that even Walter has effectively agreed with me on your "Demunging erroneous terminological nomenclatural obfuscations" thread don't you? Whistling in the wind anyone?

Matthew Wilson wrote:

> 
> "Cabal" <cabalN05P4M@myrealbox.com> wrote in message news:cd6b0k$2803$2@digitaldaemon.com...
>> And do none of you morbid buggers reading this thread know anything about template specialisations and why alias's screw them up? If you do I'd appreciate you looking at the thread "Template specialisations and 'alias'". Move along now. Nothing to see here. :)
> 
> See my various posts on the NG about using the "hack" technique to get the alias'd types.
> 
> He he, nice to be on the same team for a mo, is it not? :-)

I wish I could find your posts to check them out. Nothing comes up with template, alias or hack in the subject. And the group isn't on google yet so I can't search bodies - maybe I need a different reader.