www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - catch(Error)

reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
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
Jul 15 2004
next sibling parent Trejkaz Xaoza <trejkaz xaoza.net> writes:
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.)
Jul 15 2004
prev sibling next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
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/
Jul 15 2004
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"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


 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


 Fault?

 Notwithstanding this caving, I'm still waiting for someone to explain to me


 it's legitimate to continue execution of a process in an invalid state. I


 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. ;)
Jul 15 2004
parent "Walter" <newshound digitalmars.com> writes:
"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

 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>.
Jul 16 2004
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
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
Jul 15 2004
parent reply "Matthew Wilson" <admin.hat stlsoft.dot.org> writes:
"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


 it's legitimate to continue execution of a process in an invalid state.


 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 ... :-)
Jul 15 2004
parent Derek Parnell <derek psych.ward> writes:
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


 it's legitimate to continue execution of a process in an invalid state.


 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
Jul 15 2004
prev sibling next sibling parent reply "Marc" <iam here.net> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote...
 Notwithstanding this caving, I'm still waiting for someone to explain to

 it's legitimate to continue execution of a process in an invalid state. I

 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
Jul 15 2004
parent reply "Matthew Wilson" <admin.hat stlsoft.dot.org> writes:
"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

 it's legitimate to continue execution of a process in an invalid state.


 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. :-)
Jul 15 2004
next sibling parent reply Derek Parnell <derek psych.ward> writes:
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
Jul 15 2004
parent reply Mike Swieton <mike swieton.net> writes:
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* (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. 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. 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. 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
Jul 15 2004
next sibling parent reply "Vathix" <vathixSpamFix dprogramming.com> writes:
 Now, what is an unrecoverable error, I'm not sure (beyond the obvious:

 pointer errors, nuclear bombs, etc.). I think that's a much more

 discussion.

 Mike Swieton
 __
 About the use of language: it is impossible to sharpen a pencil with a

 axe. It is equally vain to try to do it with ten blunt axes instead.
 - Edsger Dijkstra

Well, I don't think a null pointer error is so unrecoverable. If you overwrite memory accidentally, that code usually isn't the piece that suffers from it. You've made the OS or something else suffer. If I get an access violation exception, who is to say it's so definitely unrecoverable? For example, say my news server dereferences a null pointer in the delete article function, should that take down the whole server or just abort the delete?.. my choice would be to continue running the server until I fix the function; it's not hurting anything.
Jul 15 2004
parent Florian RIVOAL <Florian_member pathlink.com> writes:
Well, I don't think a null pointer error is so unrecoverable. If you
overwrite memory accidentally, that code usually isn't the piece that
suffers from it. You've made the OS or something else suffer. If I get an
access violation exception, who is to say it's so definitely unrecoverable?
For example, say my news server dereferences a null pointer in the delete
article function, should that take down the whole server or just abort the
delete?.. my choice would be to continue running the server until I fix the
function; it's not hurting anything.

well, if you get a access Violation, it means that the system detected your atempt to write to the wrong place, and refused it. this is recoverable, because you are not in a invalid state. you are still in a valid state, but could not manage to do something. But if you actualy write in a area of memory where you do have writing acces-right, there is a chance that you will blast some data or code. after that, you are in an invalid state, or inconsistant state if you prefer. If later, some part of the program realise that something is not as it should be, there is in the general case no proper way to recover, because when the error is detected, there is no clue of what cause this error, or if the error you found out is the original problem, or a consequence of the orriginal problem. Now how the "error" can be detected and raised, that's an other problem" That's my understanding of "invalid state". To sum up, it is different from exceptions in this way: Exceptions: Generaly the program should do XXX, but under Exceptional circumstances it might happen that YYY, in this case perfom ZZZ. or in programming language : try {XXX} catch (YYY){ZZZ} Error are not things that happen under exceptional circumstances. they are things that should never happen. they are not exceptional situation, but abnormal situation. I guess nobody would like to try to recover from "if(false) raise UnrecoverableError;" simply because you have no clue why this could happen, and therefore, no reasonable way to fix it. some might say "try again" ok, try what? "re-initialize" ok, but what? the last object created? the system? the printer? your neighbour's bluetooth mobile phone? Now, implementation considerations are another problem: Terminate is a reasonable option. because since you are in a situation that should not possibly happen, you can't know what will happen if you continue. But then a good question is terminate what? the current action, the thread, the whole program, the opperating system, the nuclear reactor? It can also be argued that while you can't know what will happen if you continue, there is not much more certitude about what will happen if you stop. Automatic detecting error (in this understanding of the term) is also quite a problem. I am not sure even sure this problem has a solution. Using asserts can be a reasonable maunal alternative, but of course, you can only assert a limited number of things. And then, even if it is possible to detect automaticaly some errors, i am not sure either it is possible to put a clear limit between "extremely rare an nasty exceptions, that is going to be hard to recover from" an plain errors. So in my view, while "errors" and "invalid state" are notions that do make sense, it might not realy be realistic to try to implement it in a different way than exceptions. inheriting errors from exception is a simple way to say : hey, here is something unusual (exception), and a bad one (error).
Jul 16 2004
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 16 Jul 2004 00:44:56 -0400, Mike Swieton 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.

Yes he was, and I quote "can someone explain to me how passing NULL to strcpy() can be recoverable?" Matthew: If you were really talking about the specific situation of a program attempting to derefence a NULL pointer, why didn't you say that ;-) I was just explaining to Matthew _how_ passing NULL to strcpy() _could_ be recoverable. Not strcpy() *using*, but strcpy() being *passed*, a NULL. Sorry that I was too literal-minded.
 And by the way, while strcpy could have been implemented the way you
 describe, it wasn't. 

By "it wasn't" do you mean that "in some instances it hasn't been impemented that way"? Because I know of at least one instance in which it was implemented that way. And is there any reason why it could not be changed in D to do such?
And since not all code is written to handle those cases,
 the errors *can* occur.

No argument there.
 Consider this code:
 
 int *foo;
 *foo = 45;
 
 What does it do?

If the compiler doesn't catch it, it tries to assign 45 to somewhere unknown in RAM. But there I go being literal-minded again.
 Well, it's obviously invalid.

Unless that's what the coder intended to do ;-)
 The point is, you've just
 written to *somewhere* (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.

Yep to all of the above.
 Now here's the salient point: there _are_ errors out there which are
 unrecoverable. 

Agreed. Just as there _are_ errors out there which are recoverable.
 Matthew's suggestion was to put them into an *Error class
 hierarchy.

Fine. So Error (uppercase) is a class to handle the subset of errors (lowercase) that are unrecoverable.
 Now maybe Error is a bad term, because it sounds recoverable.

Well...the English term 'error' can include both unrecoverable and recoverable situations.
 But I
 think it's reasonable to say that you don't try to recover from
 unrecoverables,

Yeah. And its _also_ reasonable to try to recover from recoverables.
 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.

Agreed. And maybe 'unrecoverable' can be further subdivided based on the reason for being unrecoverable. ** Because it's physically impossible ** Because we don't have enough resources (time, RAM, ...) to do it ** Because we don't actually know the cause of the error ** Because we don't actually know what the error is ** Because we don't actually know what the error did to our system ** Because the coder can't be bothered trying to work out how to recover * . . . -- Derek Melbourne, Australia 16/Jul/04 4:09:52 PM
Jul 15 2004
parent reply Re: catch(Error) <Re:_member pathlink.com> writes:
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."
Jul 15 2004
next sibling parent reply "Matthew Wilson" <admin.hat stlsoft.dot.org> writes:
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.

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

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


"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

 programming techniques forum where it belongs.

 From the overview: "D ... doesn't come with ... a religion, or an

 philosophy."

Jul 16 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
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/
Jul 16 2004
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"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/

Jul 16 2004
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 16 Jul 2004 06:54:01 +0000 (UTC), Re: catchError wrote:

 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.

I was not aware that I had wandering into another world. Thank so much for pointing out this hideous misdemeanor. I'll go flog myself now and sit in the corner until my Mummy comes home.
 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. -- Derek Melbourne, Australia 16/Jul/04 5:25:32 PM
Jul 16 2004
parent "Walter" <newshound digitalmars.com> writes:
"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


 philosophy."

Well that is obviously wrong. Mr. Bright has strong views and is not

 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.
Jul 16 2004
prev sibling parent Regan Heath <regan netwin.co.nz> writes:
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/
Jul 16 2004
prev sibling parent Regan Heath <regan netwin.co.nz> writes:
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 

me how
 it's legitimate to continue execution of a process in an invalid 


 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/
Jul 16 2004
prev sibling next sibling parent reply teqDruid <me teqdruid.com> writes:
On Fri, 16 Jul 2004 09:01:02 +1000, Matthew 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 ...
 

Perhaps someone wishes to simply reinitialize the process environment and get back to work, or try again, instead of starting a new process to take it's place. If you've got worker threads working on a queue, you'd want one to move to the next item after encountering an invalid item in the queue, yes? Or am I missing the point? John
Jul 15 2004
parent "Matthew Wilson" <admin.hat stlsoft.dot.org> writes:
"teqDruid" <me teqdruid.com> wrote in message
news:pan.2004.07.16.05.13.55.753383 teqdruid.com...
 On Fri, 16 Jul 2004 09:01:02 +1000, Matthew 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 ...

Perhaps someone wishes to simply reinitialize the process environment and get back to work, or try again, instead of starting a new process to take it's place. If you've got worker threads working on a queue, you'd want one to move to the next item after encountering an invalid item in the queue, yes? Or am I missing the point?

Maybe. I'm getting the feeling I've not expressed it correctly. Basically, the nuclear reactor example somewhere on this thread is the best example of what I'm saying, although Mike's recent post regarding writing to random addresses casts some white-light of clarity also.
Jul 15 2004
prev sibling next sibling parent Regan Heath <regan netwin.co.nz> writes:
On Fri, 16 Jul 2004 09:01:02 +1000, Matthew 
<admin stlsoft.dot.dot.dot.dot.org> 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 ...

Does the failure of one strcpy call put your app into an invalid state? I believe this question has a different answer depending on the app, and what it was actually doing with the strcpy. Perhaps that is where our opinions differ. I suspect you believe the answer is "yes" in all cases? Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 16 2004
prev sibling next sibling parent Hauke Duden <H.NS.Duden gmx.net> writes:
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
 
 

Jul 16 2004
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"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

 errors in Phobos. Walter, what do you think about renaming the Error

 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

 it's legitimate to continue execution of a process in an invalid state. I

 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.
Jul 16 2004