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

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

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

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

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

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

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

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

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

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/