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

In article <cd72c1$2hgm$1@digitaldaemon.com>, Matthew says...
>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 ...

Depends how serious the error is, I guess.  Pretty much every Error in Java gets ignored by the developer and causes the application to die, though.  The only exception (no pun intended) to that rule seems to be OutOfMemoryError, which must be about the only Error which occurs in normal operation.  User opens a file which causes too much memory to be allocated, you catch the OutOfMemoryError, drop the references to all the other junk you already allocated, and then show a friendly error message.

I don't know in which hierarchy the OutOfMemoryError would be in D's case, though.  For all I know, it might be OutOfMemoryException.  (That would certainly make more sense, given common experience with Java.)

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

Some of us enjoy living dangerously. Like running with scissors.


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

"J C Calvarese" <jcc7@cox.net> wrote in message news:cd755u$2i5o$1@digitaldaemon.com...
> 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
>
> Some of us enjoy living dangerously. Like running with scissors.

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

On Fri, 16 Jul 2004 09:01:02 +1000, Matthew wrote:

[snip]

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

Maybe sometimes, the invalid state is not permanant or unrecoverable. It might be possible to perform some alternate operations that have a chance to restore the process state to a point in which execution can resume. I'm think along the lines of writing to some medium (eg.Floppy disk) and it fills up before you have finished. Or you need to access a device that is off-line and the operator can (maybe) place it back on-line.

-- 
Derek
Melbourne, Australia
16/Jul/04 11:46:38 AM

"Derek Parnell" <derek@psych.ward> wrote in message news:cd7c9p$2kg7$1@digitaldaemon.com...
> On Fri, 16 Jul 2004 09:01:02 +1000, Matthew wrote:
>
> [snip]
>
> > 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 ...
>
> Maybe sometimes, the invalid state is not permanant or unrecoverable. It might be possible to perform some alternate operations that have a chance to restore the process state to a point in which execution can resume. I'm think along the lines of writing to some medium (eg.Floppy disk) and it fills up before you have finished. Or you need to access a device that is off-line and the operator can (maybe) place it back on-line.

But that's not a case of your program being in an invalid state. It's external environment has done something unacceptable. That doesn't make your program invalid.

I'm really wondering whether I've explained myself well at all, since virtually no-one seems to get what I'm saying. :(

Too late now, I have much DTL to do before next week ... :-)

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

Marc

On Fri, 16 Jul 2004 12:34:56 +1000, Matthew Wilson wrote:

> "Derek Parnell" <derek@psych.ward> wrote in message news:cd7c9p$2kg7$1@digitaldaemon.com...
>> On Fri, 16 Jul 2004 09:01:02 +1000, Matthew wrote:
>>
>> [snip]
>>
>>> 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 ...
>>
>> Maybe sometimes, the invalid state is not permanant or unrecoverable. It might be possible to perform some alternate operations that have a chance to restore the process state to a point in which execution can resume. I'm think along the lines of writing to some medium (eg.Floppy disk) and it fills up before you have finished. Or you need to access a device that is off-line and the operator can (maybe) place it back on-line.
> 
> But that's not a case of your program being in an invalid state. It's external environment has done something unacceptable. That doesn't make your program invalid.
> 
> I'm really wondering whether I've explained myself well at all, since virtually no-one seems to get what I'm saying. :(
> 
> Too late now, I have much DTL to do before next week ... :-)

Well it maybe because you have a circular argument. You seem to be defining "invalid state" as 'a state in which it it illegitimate to continue execution'. And given that definition, then nobody can give you the paradoxical situation - i.e. one in which "it's legitimate to continue execution of a process in an invalid state".

-- 
Derek
Melbourne, Australia
16/Jul/04 12:46:10 PM

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

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

On Fri, 16 Jul 2004 12:53:07 +1000, Matthew Wilson wrote:

[snip]

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

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

It point being: strcpy() handles its arguments, and the caller of strcpy
needs to handle the results of calling strcpy().

-- 
Derek
Melbourne, Australia
16/Jul/04 1:00:59 PM