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




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


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




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




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


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


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


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


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


general

 programming techniques forum where it belongs.

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


overriding

 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




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


 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 

way here is where the app would terminate, in my world the app catches the 

records.

Now, given the above...

1. _if_ the app's main purpose was processing those records and there was 

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 

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


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