"Cabal" <cabalN05P4M@myrealbox.com> wrote in message news:cd3us6$2pv3$1@digitaldaemon.com...
> For what it's worth, my opinion is that the only truly unrecoverable errors are hardware related and the OS is the place to handle that sort of thing (*nix core dumps and Windows... errrr what does windows do nowadays?)

In that case, alas, it's not worth very much.

> The D runtime library and/or the D designer/implementor are not in a
> position to arbitrate on the severity of error which your software may or
> may not be able to recover from.
> Any decision taken to terminate a program of mine because someone somewhere
> decided that I couldn't sort out my own crap would be viewed very dimly
> indeed. Any language with such a feature should very quickly forget about
> making an impact where production and mission critical systems are
> required.

This sounds more like a freedom fighter than a software engineer.

As I said in another post, if your process is in an invalid state, do you really want to continue? Remember HAL 9000! ;-)

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:cd3vt3$2rim$1@digitaldaemon.com...
> Maybe it would be better to rename Error to FatalError?
>
> That way misunderstandings like this would be avoided in the future.

Maybe. But it seems pretty clear. There are Exceptions. There are Errors.

Other languages have this distinction pretty clear, although I can't say, off the top of my head, whether they enforce the non-recoverability of Errors. D has this opportunity, and should take it.

btw, by non-recoverable, I'm not saying they can't be caught, I'm saying that normal execution cannot be resumed. In other words, no catch (XyzError) can be exited without the rethrowing of that Error, or the throwing of another Error type. This is analogous to the behaviour of function-try block in C++ constructors

> Hauke
>
>
> Matthew wrote:
> > "Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cd366u$1glp$1@digitaldaemon.com...
> >
> >>In article <cd34hk$1dml$1@digitaldaemon.com>, Matthew says...
> >>
> >>I agree with most of what you said, apart from this bit...
> >>
> >>
> >>>(Remember, Error is
> >>>non-recoverable.)
> >>
> >>Says who? Why on EARTH would you want ANYTHING to be unrecoverable?
> >
> >
> > That's kind of the definition of an error.
> >
> > btw, I'm starting to be won over by the power of your shouting (masking the
gaps
> > in your arguments).
> >
> >
> >>Say I write a big, multi-threaded server app, and ONE little sub-thread
throws
> >>an Error with a capital E. I can recover from that.
> >
> >
> > No you can't. The error has rendered your program in an invalid state. From
that
> > point on you have no (I'm tempted to shout here), I repeat _no_, guarantees
as to
> > any future behaviour.
> >
> >
> >>For example, I write some rival to Microsoft Word. The User is editing ten documents at once. ONE of them throws an error. Why do I have to shut down
the
> >>other nine?
> >
> >
> > Because your program might do absolutely anything if you continue. You
might - as
> > I've done in the past in just such a circumstance with Dev Studio - try and
save
> > a few last changes to one or more of those documents and lose the entire
file,
> > not just the changes.
> >
> >
> >>I don't agree that Errors should be non-recoverable.
> >
> >
> > That's evident, and you're perfectly within your rights to think whatever you like. I don't think that Australians are good at sport, or that I'm going to loose my hair and develop a paunch.
> >
> >
> >>If I can deal with it
> >>safely, I should be allowed so to do.
> >
> >
> > If you can deal with it safely, then it's not an error.
> >
> >
> >>On the agreement front, though, a nice well document heirarchy of errors and exceptions would be great.
> >>
> >>Where does OutOfMemory fit into this hierarchy? (And I *definitely* want to
be
> >>able to recover from that!).
> >
> >
> > OutOfMemory is an exception, not an error, so you can recover from it. (Of course, you might be catching another pretty soon after, but that's another
matte
> > r.)
> >
> > In terms of where it fits, until and unless we get a ResourceException
sub-tree,
> > I'd say it can just live under Exception.
> >
> >
> >
> >
> >

I agree , i had 'nt noticed this before what erors in phobos are unrecoverable ones ?

Charlie

In article <cd3us6$2pv3$1@digitaldaemon.com>, Cabal says...
>
>For what it's worth, my opinion is that the only truly unrecoverable errors
>are hardware related and the OS is the place to handle that sort of thing
>(*nix core dumps and Windows... errrr what does windows do nowadays?)
>The D runtime library and/or the D designer/implementor are not in a
>position to arbitrate on the severity of error which your software may or
>may not be able to recover from.
>Any decision taken to terminate a program of mine because someone somewhere
>decided that I couldn't sort out my own crap would be viewed very dimly
>indeed. Any language with such a feature should very quickly forget about
>making an impact where production and mission critical systems are
>required.

"Sean Kelly" <sean@f4.ca> wrote in message news:cd419i$2uh6$1@digitaldaemon.com...
> In article <cd34hk$1dml$1@digitaldaemon.com>, Matthew says...
> >
> >I was going to suggest that we create some (more) standard exceptions.
However,
> >in grepping phobos 0.95, I'm pretty disturbed by what I find. Please consult
the
> >list below prior to considering the following criticisms:
> >
> >1. I have qualms about Error being derived from Exception. (Remember, Error is non-recoverable.) I presume there's no "smarts" in the current runtime
handling
> >to prevent Error, or its derivatives, from being caught? This is bad, and must
be
> >fixed. I think any catch clause that catches an Error (or one of its derived
> >types) may not exit without (re-)throwing an Error (or one of its derived
types).
> >Leaving this out should result in implicit rethrowing of the caught error
object.
> >
> >2. There seem to be almost half of the exceptions/errors are in the wrong hierarchy.
>
> It seems that the problem is that D's current use of "Error" doesn't match what you consider its established semantic meaning to be.  To me, an Error is just
an
> exception that can contain other exceptions.  Should there perhaps be two heirarchies: RecoverableError and NonRecoverableError?  Or might it be better
to
> have language support for this?

From object.d:

"
// Recoverable errors

class Exception : Object
{
    char[] msg;

    this(char[] msg);
    void print();
    char[] toString();
}

// Non-recoverable errors

class Error : Exception
{
    Error next;

    this(char[] msg);
    this(char[] msg, Error next);
}

"

Now this might not be the most diseminated documentation, but it's there, it's reflective of Walter's intention, and it's in accordance with accepted terminology. It seems to me that the straightforward approach to this is that the behaviour of Error-catching is tightened up, then well publicised, and the D community simply adopt the terminology that Walter has set out (and that is widely recognised by other communities).

In other words, in a short space of time, when someone uses the term Error, everyone will share the interpretation that it means NonRecoverableError. There are no RecoverableErrors; they're exceptions.

Did someone run over your favourite dog today Matthew? You've been arsey as a first response all day. Not that I mind if you don't mind getting it back - I'm too old and ugly to take shit without some payback.

But anyway keeping it impersonal...

>> The D runtime library and/or the D designer/implementor are not in a
>> position to arbitrate on the severity of error which your software may or
>> may not be able to recover from.
>> Any decision taken to terminate a program of mine because someone
>> somewhere decided that I couldn't sort out my own crap would be viewed
>> very dimly indeed. Any language with such a feature should very quickly
>> forget about making an impact where production and mission critical
>> systems are required.
> 
> This sounds more like a freedom fighter than a software engineer.

I suspect many 'software engineers' aren't so far up their own arses to realise that most good development is a little training, alot of experience and equal parts gut feel and black magic. Unless of course you work for EDS or some similar large systems consultancy where to suggest that would not be wise in the face that next big government contract. Maybe some of them would like to be freedom fighters.

It actually sounds more like someone who has learned not to trust decisions
made by someone far far away who doesn't have a clue what my code is
intended to do or how it is intended to react.
Define an invalid state. Define how you decide its an invalid state. If your
code decides that it has detected an invalid state how do you know that the
invalid state is not actually in your invalid state detection code. Invalid
states are not detectable internally by a process. It's like asking someone
to evaluate objectively whether they are sane or not.
And having detected this invalid state is the only response immediate and
total shutdown. Can I not isolate the problem? Am I not considered bright
enough to be trusted to do that with my own code? Is a failsafe mode not an
option?
eg. After 2 years of intensive testing in which time no errors were detected
the nuclear power plant went operational: unfortunately the software
detected an invalid state and killed itself, taking out a two mile section
of <insert favourite country>. Yes, it would have been nice if it would
have shutown the reactor first, but hey, XYZ decided 5 years ago that we
shouldn't do that.
I could ramble on for ages but I have a feeling that this going to be one of
those tin-hat thingies with barrages going back and forth for years. So
I'll save me ammo up for later :)

> 
> As I said in another post, if your process is in an invalid state, do you really want to continue? Remember HAL 9000! ;-)

Yes I remember HAL 9000. He was in an invalid state only in so far as his
human crew were concerned - given his head he would completed his mission
successfully, sans humans. Error 'corrected'. It took an external agency,
Dave, to detect he had an error and to decide to terminate the process.
As speculation, don't you think that the programmer capable of HAL would
have implemented internal error detection logic of the sort you advocate?
If he did, it didn't work very well. And if he didn't then I'll bow to that
greater intellect.

And I'll contradict myself slightly here as well. I do consider that *some* invalid states may be detectable in *some* extremely limited situations but that the effort required to detect them far outweighs the benefits and false positives will be an issue. And having detected them I'll still be pissed if the damn process terminates itself!

In article <cd481l$adi$1@digitaldaemon.com>, Matthew says...
>
>Now this might not be the most diseminated documentation, but it's there, it's reflective of Walter's intention, and it's in accordance with accepted terminology. It seems to me that the straightforward approach to this is that the behaviour of Error-catching is tightened up, then well publicised, and the D community simply adopt the terminology that Walter has set out (and that is widely recognised by other communities).
>
>In other words, in a short space of time, when someone uses the term Error, everyone will share the interpretation that it means NonRecoverableError. There are no RecoverableErrors; they're exceptions.

And I usually check the source files first... ah well :)  Works for me.  I'm deriving everything from Exception anyway, so I guess all I need to do is rename some things to omit the "Error" suffix.  In this case, I agree that Error should perhaps not inherit from Exception, as the generic catchall:

catch( Exception e ) {}

could accidentally recover from things that should cause the program to terminate.


Sean

Matthew wrote:
> "Hauke Duden" <H.NS.Duden@gmx.net> wrote in message
> news:cd3vt3$2rim$1@digitaldaemon.com...
> 
>>Maybe it would be better to rename Error to FatalError?
>>
>>That way misunderstandings like this would be avoided in the future.
> 
> 
> Maybe. But it seems pretty clear. There are Exceptions. There are Errors.

Yeah, but you have to know this particular definition of Error to understand which class should be the base class for your exceptions.

It is misleading. After all an I/O error is an error (in every day talk), right? But since it is definitely recoverable it shouldn't be derived from Error. But you have to know that and programmers are famous for not reading documentation when the meaning is "obvious".

And since error conditions often occur rarely and are often not tested (at least not thoroughly), programmers may not even realize their mistake.

I'm predicting that if the name is not changed we will see quite a few libraries and applications where all exceptions are derived from Error.

Better make it explicitly clear while we still can without too much inconvenience.

Hauke

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:cd4dla$lk5$1@digitaldaemon.com...
> Matthew wrote:
> > "Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:cd3vt3$2rim$1@digitaldaemon.com...
> >
> >>Maybe it would be better to rename Error to FatalError?
> >>
> >>That way misunderstandings like this would be avoided in the future.
> >
> >
> > Maybe. But it seems pretty clear. There are Exceptions. There are Errors.
>
> Yeah, but you have to know this particular definition of Error to understand which class should be the base class for your exceptions.

Agreed. But AFIAK - which may not be that far - the distinction between Error and Exception is as I've outlined.

> It is misleading. After all an I/O error is an error (in every day
> talk), right?

Yes

> But since it is definitely recoverable it shouldn't be derived from Error.

Indeed

> But you have to know that and programmers are famous
> for not reading documentation when the meaning is "obvious".

Sure. But the vaguaries of the English language (or any other, I imagine) are such that people misuse terminology. Look at the poor abuse of words such as infer, criticise, fantastic, etc. etc.

We have to make a line in the sand, and then set the right example, no? Otherwise what: do we just throw our hands in the air and give up?

> And since error conditions often occur rarely and are often not tested (at least not thoroughly), programmers may not even realize their mistake.

Quite true. However, it's already trivially easy to find misnamed classes, as I showed last night. My search only took five minutes.

The detection of a class called Error deriving from Exception and not Error is eminently instrumentable, and would be plugged into any "DLint". In fact, I'd suggest that the D compiler issues an error (hah!) for any .*Error derived from Exception, or vice versa.

> I'm predicting that if the name is not changed we will see quite a few libraries and applications where all exceptions are derived from Error.

Well, my position is that none of those will make it into Phobos. The convention - and remember this convention already exists, it's just been misused/ignored - will be clearly documented on the D docs, and in D books, and will be strictly enforced in the D libraries. If someone wants to be perverse and/or cavalier, well, there's no accounting for Machiavelli.

> Better make it explicitly clear while we still can without too much inconvenience.

Exactly. That's why I've mounted the soapbox.

Walter, it's about time we heard from you on this. Please save us all weeks of endless debate/posturing by dropping some crumbs.

"Cabal" <cabalN05P4M@myrealbox.com> wrote in message news:cd4ajj$ffi$1@digitaldaemon.com...
> Did someone run over your favourite dog today Matthew? You've been arsey as a first response all day. Not that I mind if you don't mind getting it back

Not sure. I've finished my book and its CD, I start some interesting paying work next week. I've got a little too much on my plate, but I don't think that's it.

It might be a documentary on North Korean prison camps I watched yesterday. It discussed things too terrible to contemplate, especially to anyone with kids. I've not been able get it out of my mind since. :(

Anyway, sorry for the ill-manners. (Being crotchety is another matter, let's just hope it wears off

> - I'm too old and ugly to take shit without some payback.

Me too. Pay away. :)

> But anyway keeping it impersonal...
>
> >> The D runtime library and/or the D designer/implementor are not in a
> >> position to arbitrate on the severity of error which your software may or
> >> may not be able to recover from.
> >> Any decision taken to terminate a program of mine because someone
> >> somewhere decided that I couldn't sort out my own crap would be viewed
> >> very dimly indeed. Any language with such a feature should very quickly
> >> forget about making an impact where production and mission critical
> >> systems are required.
> >
> > This sounds more like a freedom fighter than a software engineer.
>
> I suspect many 'software engineers' aren't so far up their own arses to realise that most good development is a little training, alot of experience and equal parts gut feel and black magic. Unless of course you work for EDS or some similar large systems consultancy where to suggest that would not be wise in the face that next big government contract. Maybe some of them would like to be freedom fighters.

Agree with all that. :)

> It actually sounds more like someone who has learned not to trust decisions made by someone far far away who doesn't have a clue what my code is intended to do or how it is intended to react.

It may do. Alternatively, it may sound like someone who knows what they're talking about, as I'm quite sure B Meyer and W Bright do, and I'm somewhat confident I do.

> Define an invalid state. Define how you decide its an invalid state. If your code decides that it has detected an invalid state how do you know that the invalid state is not actually in your invalid state detection code.

Simple. It either satisfies the contract or it doesn't. If it does, then it's within the purview of the function/class. If it doesn't, it's within the purview of the client code, and the only sensible recourse for the function/class is to fire its assertion. (Again, whatever "fire" is is immaterial to the argument.)

> Invalid
> states are not detectable internally by a process.

Utterly disagree. If you attempt to dereference a null pointer, I'm pretty sure the process (helped by the hardware) can tell you that its now in an invalid state. Please explain otherwise.

> It's like asking someone
> to evaluate objectively whether they are sane or not.

Perhaps. The analogy's too weak to prove that, however, since I might say "that's true" and mean it's supporting of my POV.

> And having detected this invalid state is the only response immediate and total shutdown.

The only response is to halt. The definition of halt depends on the circumstances, and can be pretty much anything that results in a timely termination of the process

> Can I not isolate the problem?

No. You've put part/all your process in an invalid state. How do you come back from that?

> Am I not considered bright
> enough to be trusted to do that with my own code?

The question is disengenuous, and attempts to beguile.

1. You are clearly bright enough to be writing quality software, as are most
members of this NG - I'm not saying otherwise.
2. I'm not talking about "your own code", per se. Consider you're using some
other library. If you violate its contract, how is it expected to behave? Should
it spawn a subroutine that initiates an SMS conversation with its original
author, who can interpret what you meant, rather than what you said?

> Is a failsafe mode not an
> option?

No. If a given library needs to cater for a wide range of conditions, some of which are erroneous, then that's part of its contract.

> eg. After 2 years of intensive testing in which time no errors were detected the nuclear power plant went operational: unfortunately the software detected an invalid state and killed itself, taking out a two mile section of <insert favourite country>. Yes, it would have been nice if it would have shutown the reactor first, but hey, XYZ decided 5 years ago that we shouldn't do that.

This is just rot.

(btw, can I insert a couple of countries that I _don't_ like? <g>)

> I could ramble on for ages but I have a feeling that this going to be one of those tin-hat thingies with barrages going back and forth for years. So I'll save me ammo up for later :)

You can ramble as much as you like. You won't change my opinion, nor that of the many esteemed engineers who ascribe to DbC. (One of which invented D, and writes our compiler.)

> > As I said in another post, if your process is in an invalid state, do you really want to continue? Remember HAL 9000! ;-)
>
> Yes I remember HAL 9000. He was in an invalid state only in so far as his
> human crew were concerned - given his head he would completed his mission
> successfully, sans humans. Error 'corrected'. It took an external agency,
> Dave, to detect he had an error and to decide to terminate the process.
> As speculation, don't you think that the programmer capable of HAL would
> have implemented internal error detection logic of the sort you advocate?
> If he did, it didn't work very well. And if he didn't then I'll bow to that
> greater intellect.

Can't answer. Sides are splitting.

> And I'll contradict myself slightly here as well. I do consider that *some* invalid states may be detectable in *some* extremely limited situations but that the effort required to detect them far outweighs the benefits and false positives will be an issue. And having detected them I'll still be pissed if the damn process terminates itself!

Let me ask you to address your notions to a very simple case: strcpy().

Bear in mind that strcpy's signature is

    char *strcpy(char *dest, char const *src);

and that it always returns dest.

What should strcpy do if its passed a null pointer for its source string?
What about a null pointer for its destination string?
How should it indicate error?
How should client code of strcpy() detect, and react to, errors?

When you've replied, I'll tell you a simple, but rather nasty story, about Borland and Microsoft.

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cd4kln$13ot$1@digitaldaemon.com...
>
> "Cabal" <cabalN05P4M@myrealbox.com> wrote in message news:cd4ajj$ffi$1@digitaldaemon.com...
> > Did someone run over your favourite dog today Matthew? You've been arsey as a first response all day. Not that I mind if you don't mind getting it back
>
> Not sure. I've finished my book and its CD, I start some interesting paying
work
> next week. I've got a little too much on my plate, but I don't think that's it.
>
> It might be a documentary on North Korean prison camps I watched yesterday. It discussed things too terrible to contemplate, especially to anyone with kids. I've not been able get it out of my mind since. :(
>
> Anyway, sorry for the ill-manners. (Being crotchety is another matter, let's
just
> hope it wears off
>
> > - I'm too old and ugly to take shit without some payback.
>
> Me too. Pay away. :)
>
> > But anyway keeping it impersonal...
> >
> > >> The D runtime library and/or the D designer/implementor are not in a
> > >> position to arbitrate on the severity of error which your software may or
> > >> may not be able to recover from.
> > >> Any decision taken to terminate a program of mine because someone
> > >> somewhere decided that I couldn't sort out my own crap would be viewed
> > >> very dimly indeed. Any language with such a feature should very quickly
> > >> forget about making an impact where production and mission critical
> > >> systems are required.
> > >
> > > This sounds more like a freedom fighter than a software engineer.
> >
> > I suspect many 'software engineers' aren't so far up their own arses to realise that most good development is a little training, alot of experience and equal parts gut feel and black magic. Unless of course you work for EDS or some similar large systems consultancy where to suggest that would not be wise in the face that next big government contract. Maybe some of them would like to be freedom fighters.
>
> Agree with all that. :)
>
> > It actually sounds more like someone who has learned not to trust decisions made by someone far far away who doesn't have a clue what my code is intended to do or how it is intended to react.
>
> It may do. Alternatively, it may sound like someone who knows what they're talking about, as I'm quite sure B Meyer and W Bright do, and I'm somewhat confident I do.
>
> > Define an invalid state. Define how you decide its an invalid state. If your code decides that it has detected an invalid state how do you know that the invalid state is not actually in your invalid state detection code.
>
> Simple. It either satisfies the contract or it doesn't. If it does, then it's within the purview of the function/class. If it doesn't, it's within the
purview
> of the client code, and the only sensible recourse for the function/class is to fire its assertion. (Again, whatever "fire" is is immaterial to the argument.)
>
> > Invalid
> > states are not detectable internally by a process.
>
> Utterly disagree. If you attempt to dereference a null pointer, I'm pretty sure the process (helped by the hardware) can tell you that its now in an invalid state. Please explain otherwise.
>
> > It's like asking someone
> > to evaluate objectively whether they are sane or not.
>
> Perhaps. The analogy's too weak to prove that, however, since I might say
"that's
> true" and mean it's supporting of my POV.
>
> > And having detected this invalid state is the only response immediate and total shutdown.
>
> The only response is to halt. The definition of halt depends on the circumstances, and can be pretty much anything that results in a timely termination of the process
>
> > Can I not isolate the problem?
>
> No. You've put part/all your process in an invalid state. How do you come back from that?
>
> > Am I not considered bright
> > enough to be trusted to do that with my own code?
>
> The question is disengenuous, and attempts to beguile.
>
> 1. You are clearly bright enough to be writing quality software, as are most
> members of this NG - I'm not saying otherwise.
> 2. I'm not talking about "your own code", per se. Consider you're using some
> other library. If you violate its contract, how is it expected to behave?
Should
> it spawn a subroutine that initiates an SMS conversation with its original author, who can interpret what you meant, rather than what you said?
>
> > Is a failsafe mode not an
> > option?
>
> No. If a given library needs to cater for a wide range of conditions, some of which are erroneous, then that's part of its contract.
>
> > eg. After 2 years of intensive testing in which time no errors were detected the nuclear power plant went operational: unfortunately the software detected an invalid state and killed itself, taking out a two mile section of <insert favourite country>. Yes, it would have been nice if it would have shutown the reactor first, but hey, XYZ decided 5 years ago that we shouldn't do that.
>
> This is just rot.
>
> (btw, can I insert a couple of countries that I _don't_ like? <g>)
>
> > I could ramble on for ages but I have a feeling that this going to be one of those tin-hat thingies with barrages going back and forth for years. So I'll save me ammo up for later :)
>
> You can ramble as much as you like. You won't change my opinion, nor that of
the
> many esteemed engineers who ascribe to DbC. (One of which invented D, and
writes
> our compiler.)
>
> > > As I said in another post, if your process is in an invalid state, do you really want to continue? Remember HAL 9000! ;-)
> >
> > Yes I remember HAL 9000. He was in an invalid state only in so far as his
> > human crew were concerned - given his head he would completed his mission
> > successfully, sans humans. Error 'corrected'. It took an external agency,
> > Dave, to detect he had an error and to decide to terminate the process.
> > As speculation, don't you think that the programmer capable of HAL would
> > have implemented internal error detection logic of the sort you advocate?
> > If he did, it didn't work very well. And if he didn't then I'll bow to that
> > greater intellect.
>
> Can't answer. Sides are splitting.
>
> > And I'll contradict myself slightly here as well. I do consider that *some* invalid states may be detectable in *some* extremely limited situations but that the effort required to detect them far outweighs the benefits and false positives will be an issue. And having detected them I'll still be pissed if the damn process terminates itself!
>
> Let me ask you to address your notions to a very simple case: strcpy().
>
> Bear in mind that strcpy's signature is
>
>     char *strcpy(char *dest, char const *src);
>
> and that it always returns dest.
>
> What should strcpy do if its passed a null pointer for its source string?
> What about a null pointer for its destination string?
> How should it indicate error?
> How should client code of strcpy() detect, and react to, errors?
>
> When you've replied, I'll tell you a simple, but rather nasty story, about Borland and Microsoft.

btw, thanks for bringing this up! I think this is a good example for the DbC section in the D book. :-)