I've said all I'm saying on this on the nuclear power plant issue. If you've anything concrete to say about that example, please do so. Otherwise, you're wasting your keystrokes, because I've stopped reading.

"Cabal" <cabalN05P4M@myrealbox.com> wrote in message news:cd86t8$1sh$1@digitaldaemon.com...
> 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?
>

I guess I was asking for this, wasn't I?

On Thu, 15 Jul 2004 06:49:10 +1000, Matthew wrote:

> 
> "John Reimer" <brk_6502@NO_SPA_M.yahoo.com> wrote in message
>>
>> I assume at one point in time, a long, long time ago, some smart computer scientists got together and decided on what constitutes an error and an exception.  After that, everybody read what they wrote and decided it must be so because smart people said so.
> 
> That's the second comment in the last few days about "smart people". Do you have a problem with smart people? If so, you'll probably take issue with most people on this NG, including, from my apprehension, yourself. :-)

What can I say?  Put in that light, it sounds like I have issues. No, I was just venting a little about people's tendency to adopt any theoretical convention without much critical thinking of their own (although, it probably was a waste of bandwidth; people here to tend to be critical thinkers and independent minded).

My point was that your perspective on errors/exceptions seemed to be presented in such a manner as "this is law, obey it" and "you are a ninny if don't do it this way."  (Likely a huge overreaction;  I apologize) And yet that which constitutes an error or exception still seemed quite open to debate. But this isn't my area of expertise, thus my request for references of further study (thank you!).

The term "smart" is entirely subjective of course.  I just use it (overuse
it?) to put across the relative evaluation that others make of
certain people or that people make of themselves. Yet apparently the
more "smart" I talk about, the more stupid I sound.  Part of being able to
write, obviously, is knowing when to write something and when not to.  I
struggle with that fine balance sometimes. So I'd better just clam up
on that topic for a bit. Now that's smart! :-)

For myself, I try to keep as far away from such ego-centric feelings I can. Past experience says that I'll be feeling horribly stupid in the near future if I entertain any excessive feelings of intelligence.

> 
>> Meanwhile, in another part of the world, in a small island in the pacific, perhaps the definitions for these terms were exchanged.
> 
> Perhaps so. But perversion/mistranslation of a definition does not change the validity of that definition

Yep... I know.  But there's usually more than one definition that
works.  Perversion/mistranslation implies that the islanders borrowed from
the mainlands definitions.  Maybe they just came up with some ideas
independently.  In the case of errors/exceptions, several definitions
would appear to be suitable. From the posts I read, people seem to have
quite an assortment of opinions.  Maybe they haven't read the book? :-)

> 
>> Since I have not studied the error/exception definition differences much myself, I was curious where I can read what these smart people have decreed about them.  Any good books about exception handling that you would recommend?
> 
> I would recommend the classic "Object Oriented Software Construction" by Bertrand Meyer, the daddy of Design by Contract.
> 
> Also, IIRC, you can glean this kind of stuff from several Stroustrup commentatries, though I can't remember any URLs.

Thanks for the book recommendations!

Have a good one,

John

I too can recommend Bertrand Meyers book John, and you'll be happy to know it doesn't agree with Matthew very much. Quite the opposite in fact :)