On Fri, 16 Jul 2004 12:53:07 +1000, Matthew Wilson <admin.hat@stlsoft.dot.org> wrote:

>
> "Marc" <iam@here.net> wrote in message
> news:cd7fcg$2m0q$1@digitaldaemon.com...
>>
>> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote...
>> > Notwithstanding this caving, I'm still waiting for someone to explain 
>> to
>> me how
>> > it's legitimate to continue execution of a process in an invalid 
>> state.
> I
>> guess
>> > I'll be waiting a long time ...
>> >
>> > Matthew
>>
>> Read this:
>>
>> http://archive.eiffel.com/doc/manuals/technology/contract/ariane/page.html
>>
>> An example of a process entering an invalid state and
>> unable to recover to a stable state.
>>
>> Whatever the name of the reason: an error, a fault, a bug, ...
>> The process must try to recover at all costs...
>>
>> Another example: would you like to be the guy trying to explain
>> to his boss: " The program in charge of controlling the core of the
>> nuclear reactor entered an invalid state, so i have made it to simply
>> stop an display a message to the operator"
>>
>> Well, those examples are a little extreme, but it depends
>> on your definition of "an invalid state".
>
> Sorry, I don't think Arianne example qualifies.
>
> I repeat, can someone explain to me how passing NULL to strcpy() can be
> recoverable? It's the simplest example I can think of, and yet no-one's
> addressed it yet.

Ok, hows this...

App takes a list of records, and writes a log entry for each one, in the process of writing log entry #5 it passes NULL to strcpy, if you had your way here is where the app would terminate, in my world the app catches the SEGV signal, logs that record #5 is corrupt and continues processing records.

Now, given the above...

1. _if_ the app's main purpose was processing those records and there was no point in processing #6 if #5 failed, perhaps it was totaling something in the records and needed all records to give a valid result, then it would be valid to terminate due to the strcpy.

2. _if_ the app's main purpose was something else entirely, and the records were unrelated, #6 could be processed if #5 failed, and #5 was not that important really and could be fixed later, then it would _not_ be valid to terminate due to the strcpy.

The choice should be in the hands of the programmer of the app, only they know the importance of the code that caused the fault.

Regan

> As for the nuclear reactor example, you're being tabloid, and not
> considering what I've said. If the reactor control software experiences a
> condition that puts it into an undefined state, there is only ONE safe thing
> to do: terminate. Now, it goes without saying part of the termination
> handler is that it drops the carbon rods, and kills the reactions.
>
> In fact, this is the perfect example of my POV, so many thanks. If the
> program faults, and therefore enters an undefined state, then to _not_
> terminate is the very worst thing because, in principle, *anything* can
> happen from this point in. Meltdown might be the next thing, or opening
> cooling vents that should never be opened, or flushing waste into the local
> water system.
>
> Cool. Now that's a brilliant example, and I am content. :-)
>
>
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Well, for one thing it might be preferable for the program to keep running slightly off-spec than to terminate it.

An example would be a critical system. Imagine a Mars satellite that encounters some kind of Error. Do you want it to shut down and burn in the atmosphere, or do you want it to continue sending any data it may still be able to retrieve? Analysts on earth would know about the error and might be able to manually clean up the data and still retrieve useful information from it.

In other words: in some cases ANY kind of reaction from the software may be preferable to having it shut down.

Hauke


Matthew wrote:
> Ok
> 
> I still think termination is the right thing, but I yield to the "Spirit of C" on
> this one, since I often tout if in support of things I do agree with.
> 
> Can we get on with sorting the naming/inheritance of all the exceptions and
> errors in Phobos. Walter, what do you think about renaming the Error hierarchy to
> Fault?
> 
> Notwithstanding this caving, I'm still waiting for someone to explain to me how
> it's legitimate to continue execution of a process in an invalid state. I guess
> I'll be waiting a long time ...
> 
> 
> Matthew
> 
> 

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cd72c1$2hgm$1@digitaldaemon.com...
> Can we get on with sorting the naming/inheritance of all the exceptions
and
> errors in Phobos. Walter, what do you think about renaming the Error
hierarchy to
> Fault?

I find Scott's taxonomy of error, fault, etc., both confusing and pointless. (sorry, Scott!). Usage of Error for non-recoverable errors has some history behind it in D and other languages, I don't find a compelling argument to change it to Fault, so let's leave it as is.

> Notwithstanding this caving, I'm still waiting for someone to explain to
me how
> it's legitimate to continue execution of a process in an invalid state. I
guess
> I'll be waiting a long time ...

Because sometimes when writing specialized apps, or debugging code, or sandboxing dlls, or need specialized shutdown code, or want to log certain kinds of faults, you'll want to catch them.

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cd79lt$2jk6$1@digitaldaemon.com...
> Ooh, don't!! It my my skin crawl. There've been too many running-with-thing-in-mouth experiences in the Wilson household over the
last few
> months. Lots of tears, shouting, and the occasional wobbly tooth. ;)

When I was 5 or so, I was running up the porch steps towards the house when I fell and hit the concrete planter with my mouth. Knocked out my front teeth. Fortunately, it was my baby teeth, and the adult teeth still came in normally. It sure hurt, though, and there were lots of tears and shouting.

I spent a couple of years without front teeth, and to this day still bite off things with the side of my mouth <g>.

"Derek Parnell" <derek@psych.ward> wrote in message news:cd80au$2v8b$1@digitaldaemon.com...
> > From the overview: "D ... doesn't come with ... a religion, or an
overriding
> > philosophy."
>
> Well that is obviously wrong. Mr. Bright has strong views and is not
afraid
> to expose them here or in his wonderful-ish language.

One man's religion is another man's myth <g>.

But I agree I have strong views about things. What I meant is that D doesn't have a overriding philosophy, like, for instance "everything must be an object" or "portability considerations trump all others". It doesn't have a religion either, like, for instance, "object-oriented programming is the best solution for every programming problem."

D doesn't have any one-size-fits-all philosophy or religion that overrides all other considerations. Overriding is the key word here, as languages that do have such will use it when it makes no sense, thereby seriously crippling the language.

On Fri, 16 Jul 2004 00:44:56 -0400, Mike Swieton <mike@swieton.net> wrote:

> On Fri, 16 Jul 2004 13:07:22 +1000, Derek Parnell wrote:
>> Okay, the purpose of strcpy() is to make a copy of any string it's passed
>> and to return the address of newly copied string, right? So if it has not
>> been passed a string, it doesn't (can't) copy it. NULL is not a string, so
>> therefore it doesn't try to copy it. It could just reflect its argument, or
>> return NULL (ie. not an address 'cos it didn't create a new string).
>
> Perhaps the problem becomes simpler when you make the example a bit more
> general. Matthew - and correct me if I'm wrong - wasn't really talking about
> passing bad arguments to a function, he's talking about dereferencing the NULL
> pointer. And by the way, while strcpy could have been implemented the way you
> describe, it wasn't. And since not all code is written to handle those cases,
> the errors *can* occur.
>
> Consider this code:
>
> int *foo;
> *foo = 45;
>
> What does it do? Well, it's obviously invalid. The point is, you've just
> written to *somewhere*

Have you? Doesn't _something_ stop the write operation and send a sig SEGV?
If the write does not actually occur then you can recover from this, as you have not entered an invalid state, just tried to accidently.

> (Actually, I believe D would initialize the pointer,
> but bear with me for the sake of argument, please, it's an illustrative
> example). Maybe you wrote over an old integer, and there's no problem. Maybe
> you're on a really primitive OS or embedded system and you just overwrote the
> kernel.

In either case, if the write occurs then I would agree you have entered an invalid state.

> Now here's the salient point: there _are_ errors out there which are
> unrecoverable. Matthew's suggestion was to put them into an *Error class
> hierarchy. Now maybe Error is a bad term, because it sounds recoverable.

I liked his seccond suggestion, was it a *Failure class heirarchy.

> But I
> think it's reasonable to say that you don't try to recover from
> unrecoverables, and that those exceptions have their own place in the
> hierarchy.
>
> Now, what is an unrecoverable error, I'm not sure (beyond the obvious: null
> pointer errors, nuclear bombs, etc.). I think that's a much more worthwhile
> discussion.

If you catch the NULL pointer and throw an exception in your API instead of doing an assert then your program does _not_ enter an invalid state, and you _can_ recover from it. This to me is the better way of dealing with it, it allows the programmer of the app using your API to choose whether to recover or not.

Regan

> Mike Swieton
> __
> About the use of language: it is impossible to sharpen a pencil with a blunt
> axe. It is equally vain to try to do it with ten blunt axes instead.
> 	- Edsger Dijkstra
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Matthew Wilson wrote:
> Seems like a stupid suggestion, and not in the least in keeping with the
> long established spirit of this NG. We're all accustomed to cherry picking
> those debates we're interested in.

Clearly, this thread isn't off-topic although I'm sure it's boring to some. (And the discussion might be stuck in a rut.) Nonetheless, some interesting points have been made. Positions have been stated, re-stated, clarified, and re-clarified. Accusations have been lodged. Apologies offered, etc. I'd call it a typical thread in D-land.

If a person finds, the first 10 "catch(Error)" posts uninteresting, it's his own fault if he insists on reading the next 10.

> Further, why not identify yourself, Miss catch(Error)?

It could have been an innocent mistake. It appears the author was posting with the oh-so-user-friendly web interface.

> 
> Overall, I think your is post pointless and forgettable. Now what was I
> saying ...

Of course, replying to pointless and forgettable posts is a good way to give them more exposure and make them more memorable.

> 
> 
> "Re: catch (Error)" <Re:_member@pathlink.com> wrote in message
> news:cd7u29$2t55$1@digitaldaemon.com...
> 
>>I was given to understand that this was D forum. Can you at least put "Off
>>topic" in the thread title, or, better still, take this discussion to a
> 
> general
> 
>>programming techniques forum where it belongs.
>>
>>From the overview: "D ... doesn't come with ... a religion, or an
> 
> overriding
> 
>>philosophy."

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

"J C Calvarese" <jcc7@cox.net> wrote in message news:cd9ncu$nr7$1@digitaldaemon.com...
> Matthew Wilson wrote:
> > Seems like a stupid suggestion, and not in the least in keeping with the long established spirit of this NG. We're all accustomed to cherry picking those debates we're interested in.
>
> Clearly, this thread isn't off-topic although I'm sure it's boring to some. (And the discussion might be stuck in a rut.) Nonetheless, some interesting points have been made. Positions have been stated, re-stated, clarified, and re-clarified. Accusations have been lodged. Apologies offered, etc. I'd call it a typical thread in D-land.

And that was my point. We have a long-established culture here of robust debate (which is almost always well-mannered), off topic musings, and even fanciful flights. If anyone doesn't like it, they should p*ss off and go somewhere where people are more exact, subject to stricture and up their own behinds. They won't need to search long for a ng like that ...

> If a person finds, the first 10 "catch(Error)" posts uninteresting, it's his own fault if he insists on reading the next 10.
>
> > Further, why not identify yourself, Miss catch(Error)?
>
> It could have been an innocent mistake. It appears the author was posting with the oh-so-user-friendly web interface.
>
> >
> > Overall, I think your is post pointless and forgettable. Now what was I saying ...
>
> Of course, replying to pointless and forgettable posts is a good way to give them more exposure and make them more memorable.

Indeed. But put a rabbit in front of a dog ... :-)



> >
> >
> > "Re: catch (Error)" <Re:_member@pathlink.com> wrote in message news:cd7u29$2t55$1@digitaldaemon.com...
> >
> >>I was given to understand that this was D forum. Can you at least put "Off topic" in the thread title, or, better still, take this discussion to a
> >
> > general
> >
> >>programming techniques forum where it belongs.
> >>
> >>From the overview: "D ... doesn't come with ... a religion, or an
> >
> > overriding
> >
> >>philosophy."
>
> -- 
> Justin (a/k/a jcc7)
> http://jcc_7.tripod.com/d/