www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Standard exceptions - some disturbing observations

reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
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.
    Surely ModuleCtorError is an error? Why is it derived from Exception? Who's
gonna catch it?
    It seems to me that DateParseError, RegExpError, URIError and UtfError (note
the inconsistent capitalisation here) are exceptions, not errors. After all,
surely the process should be able to recover from any of these conditions?
    As for StreamError and its children, I feel like tearing my hair out. These
are also most certainly *not* unrecoverable errors. Are D server processes to
terminate because they can't open a file. Argh! Furthermore, there are just too
many exception classes here,

3. Is SwitchError a class that is thrown, or simply a non-exception-like
implementation for the switch/default behaviour? If it's the former, then it
should derive from Error. If the latter, then it should be given a different
name.

4. I've noticed in much of the code, and I assume it's Walter's, that exceptions
are only thrown in one place, in a worker function, called error(). IMO, this
does not aid discoverability of the source. Using a worker's fine (although I'd
argue that in most of these cases it's a worthless convenience, since it does
nothing more than call "throw new XyzException(msg);"), but it must be called
something clearer. I want to be able to search the source for ".*Exception" and
".*Error", so such workers should be called, at least, throwException().


I was intending to suggest some more exception classes, such as
InvalidKeyException, but given the current state I hesitate to add to the mess.
This is really crappy stuff, and should be fixed as a priority. Anyone with a
qualify focus coming along new to D and looking through this will think this is
some kids project. :(

Here is the full list (using "class.*Error" and "class.*Exception" search
strings). Get your tissues handy, you'll be crying shortly.

Exception
    Base64Exception
    Base64CharException
    FileException
    ExeModuleException
    ModuleCtorError    <-- Shouldn't this be derived from Error?
    SocketException
        SocketAcceptException
    AddressException - shouldn't this be derived from SocketException??
    HostException - shouldn't this be derived from SocketException??
    StringException
    ZipException
    ZlibException
    WindowsException (was Win32Exception)
        RegistryException

    Error
        ArrayBoundsError
        AssertError
        ConvError
        ConvOverflowError
        DateParseError    <-- Shouldn't this be derived from Exception
        FormatError
        RegExpError    <-- this should be derived from Exception
        StreamError    - Eeek!!
            ReadError    - Eeek!!
            WriteError    - Eeek!!
            SeekError    - Eeek!!
            StreamFileError - Eeek!!
                OpenError
                CreateError
        ThreadError
        URIerror <-- Exception?
        UtfError <-- Exception

SwitchError (derived from Object)
Jul 14 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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?

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.

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?

I don't agree that Errors should be non-recoverable. If I can deal with it
safely, I should be allowed so to do.

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

Arcane Jill
Jul 14 2004
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"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.
Jul 14 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Maybe it would be better to rename Error to FatalError?

That way misunderstandings like this would be avoided in the future.


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.
Jul 14 2004
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"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.
Jul 14 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
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
Jul 14 2004
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"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.
Jul 14 2004
prev sibling next sibling parent "Ben Hinkle" <bhinkle mathworks.com> writes:
I agree with your suggested changes below - and also I suggest making
"ArrayBoundsError" an expection like it is in Java since indexing outside of
an array bounds is also recoverable. Same for ConvError and
ConvOverflowError: why aren't those exceptions? I wouldn't want my app to
abort because of an overflow. In fact the only thing that should subclass
Error is probably just AssertError. ThreadError could be split up because it
gets thrown, for example, when you try to start an already started thread
(should that abort?) and when there are too many threads (maybe that should
abort but personally I think that's like running out of memory and should be
recoverable).

For reference here is Java's list of Error subclasses:
AssertionError, AWTError, CoderMalfunctionError, FactoryConfigurationError,
LinkageError, ThreadDeath, TransformerFactoryConfigurationError,
VirtualMachineError
And here's the JavaDoc for Error:
<quote>
An Error is a subclass of Throwable that indicates serious problems that a
reasonable application should not try to catch. Most such errors are
abnormal conditions. The ThreadDeath error, though a "normal" condition, is
also a subclass of Error because most applications should not try to catch
it.
A method is not required to declare in its throws clause any subclasses of
Error that might be thrown during the execution of the method but not
caught, since these errors are abnormal conditions that should never occur.
<\quote>

-Ben


 Here is the full list (using "class.*Error" and "class.*Exception" search
 strings). Get your tissues handy, you'll be crying shortly.

 Exception
     Base64Exception
     Base64CharException
     FileException
     ExeModuleException
     ModuleCtorError    <-- Shouldn't this be derived from Error?
     SocketException
         SocketAcceptException
     AddressException - shouldn't this be derived from SocketException??
     HostException - shouldn't this be derived from SocketException??
     StringException
     ZipException
     ZlibException
     WindowsException (was Win32Exception)
         RegistryException

     Error
         ArrayBoundsError
         AssertError
         ConvError
         ConvOverflowError
         DateParseError    <-- Shouldn't this be derived from Exception
         FormatError
         RegExpError    <-- this should be derived from Exception
         StreamError    - Eeek!!
             ReadError    - Eeek!!
             WriteError    - Eeek!!
             SeekError    - Eeek!!
             StreamFileError - Eeek!!
                 OpenError
                 CreateError
         ThreadError
         URIerror <-- Exception?
         UtfError <-- Exception

 SwitchError (derived from Object)
Jul 14 2004
prev sibling next sibling parent "Bruno A. Costa" <bruno codata.com.br> writes:
Nothing more to say. I agree with all suggestions.

Cheers,

Bruno.

Matthew wrote:


 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.
     Surely ModuleCtorError is an error? Why is it derived from Exception?
     Who's
 gonna catch it?
     It seems to me that DateParseError, RegExpError, URIError and UtfError
     (note
 the inconsistent capitalisation here) are exceptions, not errors. After
 all, surely the process should be able to recover from any of these
 conditions?
     As for StreamError and its children, I feel like tearing my hair out.
     These
 are also most certainly *not* unrecoverable errors. Are D server processes
 to terminate because they can't open a file. Argh! Furthermore, there are
 just too many exception classes here,
 
 3. Is SwitchError a class that is thrown, or simply a non-exception-like
 implementation for the switch/default behaviour? If it's the former, then
 it should derive from Error. If the latter, then it should be given a
 different name.
 
 4. I've noticed in much of the code, and I assume it's Walter's, that
 exceptions are only thrown in one place, in a worker function, called
 error(). IMO, this does not aid discoverability of the source. Using a
 worker's fine (although I'd argue that in most of these cases it's a
 worthless convenience, since it does nothing more than call "throw new
 XyzException(msg);"), but it must be called something clearer. I want to
 be able to search the source for ".*Exception" and ".*Error", so such
 workers should be called, at least, throwException().
 
 
 I was intending to suggest some more exception classes, such as
 InvalidKeyException, but given the current state I hesitate to add to the
 mess. This is really crappy stuff, and should be fixed as a priority.
 Anyone with a qualify focus coming along new to D and looking through this
 will think this is some kids project. :(
 
 Here is the full list (using "class.*Error" and "class.*Exception" search
 strings). Get your tissues handy, you'll be crying shortly.
 
 Exception
     Base64Exception
     Base64CharException
     FileException
     ExeModuleException
     ModuleCtorError    <-- Shouldn't this be derived from Error?
     SocketException
         SocketAcceptException
     AddressException - shouldn't this be derived from SocketException??
     HostException - shouldn't this be derived from SocketException??
     StringException
     ZipException
     ZlibException
     WindowsException (was Win32Exception)
         RegistryException
 
     Error
         ArrayBoundsError
         AssertError
         ConvError
         ConvOverflowError
         DateParseError    <-- Shouldn't this be derived from Exception
         FormatError
         RegExpError    <-- this should be derived from Exception
         StreamError    - Eeek!!
             ReadError    - Eeek!!
             WriteError    - Eeek!!
             SeekError    - Eeek!!
             StreamFileError - Eeek!!
                 OpenError
                 CreateError
         ThreadError
         URIerror <-- Exception?
         UtfError <-- Exception
 
 SwitchError (derived from Object)
Jul 14 2004
prev sibling next sibling parent reply John Reimer <brk_6502 NO_SPA_M.yahoo.com> writes:
Matthew wrote:


 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.
 


< big snip >

I assume at one point in time, a long, long time ago, some smart computer
scientists got together and decided on what constitutes an error and an
exception.  After that, everybody read what they wrote and decided it must
be so because smart people said so.  

Meanwhile, in another part of the world, in a small island in the pacific,
perhaps the definitions for these terms were exchanged.

Since I have not studied the error/exception definition differences much
myself, I was curious where I can read what these smart people have decreed
about them.  Any good books about exception handling that you would
recommend?

Later,

John
Jul 14 2004
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"John Reimer" <brk_6502 NO_SPA_M.yahoo.com> wrote in message
news:cd3t9f$2ndi$1 digitaldaemon.com...

 Matthew wrote:


 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.


 < big snip >

 I assume at one point in time, a long, long time ago, some smart computer
 scientists got together and decided on what constitutes an error and an
 exception.  After that, everybody read what they wrote and decided it must
 be so because smart people said so.


That's the second comment in the last few days about "smart people". Do you have
a problem with smart people? If so, you'll probably take issue with most people
on this NG, including, from my apprehension, yourself. :-)


 Meanwhile, in another part of the world, in a small island in the pacific,
 perhaps the definitions for these terms were exchanged.


Perhaps so. But perversion/mistranslation of a definition does not change the
validity of that definition


 Since I have not studied the error/exception definition differences much
 myself, I was curious where I can read what these smart people have decreed
 about them.  Any good books about exception handling that you would
 recommend?


I would recommend the classic "Object Oriented Software Construction" by
Bertrand
Meyer, the daddy of Design by Contract.

Also, IIRC, you can glean this kind of stuff from several Stroustrup
commentatries, though I can't remember any URLs.
Jul 14 2004
parent reply John Reimer <brk_6502 NO_S_PAM.yahoo.com> writes:
I guess I was asking for this, wasn't I?

On Thu, 15 Jul 2004 06:49:10 +1000, Matthew wrote:


 
 "John Reimer" <brk_6502 NO_SPA_M.yahoo.com> wrote in message

 I assume at one point in time, a long, long time ago, some smart
 computer scientists got together and decided on what constitutes an
 error and an exception.  After that, everybody read what they wrote and
 decided it must be so because smart people said so.


 
 That's the second comment in the last few days about "smart people". Do
 you have a problem with smart people? If so, you'll probably take issue
 with most people on this NG, including, from my apprehension, yourself.
 :-)


What can I say?  Put in that light, it sounds like I have issues. No, I
was just venting a little about people's tendency to adopt any
theoretical convention without much critical thinking of their own
(although, it probably was a waste of bandwidth; people here to tend to be
critical thinkers and independent minded). 

My point was that your perspective on errors/exceptions seemed to be
presented in such a manner as "this is law, obey it" and "you are a
ninny if don't do it this way."  (Likely a huge overreaction;  I
apologize) And yet that which constitutes an error or exception still
seemed quite open to debate. But this isn't my area of expertise, thus my
request for references of further study (thank you!).

The term "smart" is entirely subjective of course.  I just use it (overuse
it?) to put across the relative evaluation that others make of
certain people or that people make of themselves. Yet apparently the
more "smart" I talk about, the more stupid I sound.  Part of being able to
write, obviously, is knowing when to write something and when not to.  I
struggle with that fine balance sometimes. So I'd better just clam up
on that topic for a bit. Now that's smart! :-)

For myself, I try to keep as far away from such ego-centric feelings I
can. Past experience says that I'll be feeling horribly stupid in the near
future if I entertain any excessive feelings of intelligence.


 

 Meanwhile, in another part of the world, in a small island in the
 pacific, perhaps the definitions for these terms were exchanged.


 
 Perhaps so. But perversion/mistranslation of a definition does not
 change the validity of that definition


Yep... I know.  But there's usually more than one definition that
works.  Perversion/mistranslation implies that the islanders borrowed from
the mainlands definitions.  Maybe they just came up with some ideas
independently.  In the case of errors/exceptions, several definitions
would appear to be suitable. From the posts I read, people seem to have
quite an assortment of opinions.  Maybe they haven't read the book? :-)


 

 Since I have not studied the error/exception definition differences
 much myself, I was curious where I can read what these smart people
 have decreed about them.  Any good books about exception handling that
 you would recommend?


 
 I would recommend the classic "Object Oriented Software Construction" by
 Bertrand Meyer, the daddy of Design by Contract.
 
 Also, IIRC, you can glean this kind of stuff from several Stroustrup
 commentatries, though I can't remember any URLs.


Thanks for the book recommendations!

Have a good one,

John
Jul 16 2004
parent Cabal <cabalN05P4M myrealbox.com> writes:
I too can recommend Bertrand Meyers book John, and you'll be happy to know
it doesn't agree with Matthew very much. Quite the opposite in fact :)
Jul 17 2004
prev sibling next sibling parent reply Cabal <cabalN05P4M myrealbox.com> writes:
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.
Jul 14 2004
next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"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! ;-)
Jul 14 2004
parent reply Cabal <cabalN05P4M myrealbox.com> writes:
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!
Jul 14 2004
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"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.
Jul 14 2004
next sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"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. :-)
Jul 14 2004
prev sibling parent reply Cabal <cabalN05P4M myrealbox.com> writes:
I've moved the individual chunks of text around so this reads a little
better.
 

 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.


Right. Dig out your copy of Meyer and re-read it. Don't go referencing it
again until you have. Chapter 7 deals with pre/post conditions and
contracts and strangely enough it doesn't mention anywhere about a process
throwing its hands in the air and terrminating itself because something
didn't happen as expected. He's quite explicit about it - if anything fails
for any reason it throws an exception, which should be caught and dealt
with and the operation possibly retried. Apparently he's quite hot on this,
there are a few Eiffel features built into the language for just this
reason. He goes even further with this logic than I have advocated, and
states that hardware detected errors can/should be caught and turned into
software exceptions which are in turn caught and dealt with and the
relevant operation retried. He even has names for the concept, which you
might have read once but have obviously forgotten 'Robustness' and
'Software Fault Tolerance'. Having skimmed the chapter quickly I can't find
anywhere were he suggests that termination is an option - certainly not an
option taken out of the programmers hands and enforced because a library
misbehaved.

 

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


Couldn't agree more, exceptions should certainly be thrown in failure
situations. I was under the impression this argument was regarding whether
'someone' (not the programmer writing the code) should be empowered to
enforce a process termination when particular exception types were
encountered.


 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.
 


Can we clarify definitions here because I get the impression we are talking
at slightly cross purposes. I have referred to 'invalid state' as meaning
that a process is in such a state that continuing correctly is simply not
possible - you defined it as such earlier. The issue at hand is what
constitutes an invalid state and how it is detected. Your example above is
most definitely *not* an example of definitive invalid process state. Sure,
95% of programs written in D or whatever else should shut down at this
point, but the other 5% of mission critical production systems should not
be forced to terminate because someone, somewhere, somewhen decided on a
blanket termination policy. You claim to quote Meyer - read chapter 7 again
and his suggestions for using the EXTERNAL_EXCEPTIONS mechanism to turn
null dereferences into software exceptions to be caught and worked around.


 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


Agreed. Where I disagree is D's ability to correctly detect an unrecoverable
invalid state. Where I disagree is the decision to have D enforce
termination in every circumstance.



 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?
 


Re-read Meyer. Is that getting boring? I only emphasize you should do this
because you are misleading others on this mailing list by mis-stating
Meyer's thoughts on this. I *am* in a position to decide on just how
recoverable my program state is.


 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.


You've seen enough of my code to make that judgement? Maybe there's an
inverse square law in operation here. You check out my 10 - 15 lines code
on the forum and decide I'm a quality programmer. You read thousands of
Meyers words of wisdom and decide... well, what did you decide? To forget
it all?


 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?
 


If the code is DbC then I expect to behave according to its contract. If
that contract is sufficiently well defined to allow me to be confident of
retrying with different data sets then I damn well want to retry. D should
*not* have carte blanche to pull my plug! A library written to DbC
standards should support retries especially well!



 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.


Repetition begins to grind me down... Meyer, meyer, meyer... Chapter 7.
Fault tolerance... gasp!


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


The particular instance may be rot because as stated previously, D would
never be allowed near a critical system given the current termination
policy.



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


DbC has nothing to do with arbitrary program termination. I quite like DbC.
I have nothing against it all and would love to come across more code
written like this. Shall I say it again for effect? DbC is wonderful and
luvverly and the best thing since sliced bread. Please don't pervert its
meaning to your dastardly ends. 


 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?


It should cause a SIGSEGV (*nix - sorry).

 What about a null pointer for its destination string?


It should cause a SIGSEGV (again *nix - don't ask me how windows deals with
it)

 How should it indicate error?


See above. I presume those are the errors you are talking about.

 How should client code of strcpy() detect, and react to, errors?


Joe Bloggs program to count sheep jumping over fences: let the OS core the
process and terminate the app. Note: D doesn't have anything to do with
this either.
My program monitoring the heart defibrillator (not that that's what I do):
Intercept (by whatever means are supported) the signal. Turn it into an
exception to throw to the caller. Caller (however many levels up the stack
- I don't expect whatever is calling strcpy to be in a position to do much
intelligent recovery) catches the exception and does whatever it has been
programmed to do. This could include:
 1) Try the next string in the vector.
 2) Decide that the message being processed was invalid. Dump it to log and
try the next message.
 3) lots of other Robust responses. Meyer. Chapter 7.
 4) Decide that the stack frame of the current thread must have been
corrupted somehow. Terminate the thread. Continue the process.
 5) Decide that the process heap is corrupt. Terminate the process.

Recap: 
a) We agree (I think) on what an invalid state is. 
b) We disagree on the point at which an invalid state can be detected. You
are talking in terms of recoverable exceptions whenever you give examples
of process terminating invalid states.
c) As a consequence of b) you are advocating brittle termination of possibly
perfectly viable processes. The point being that no-one except the person
programming it can know in advance when it has become invalid.
d) Don't terminate my process because it does stuff you don't like. I'm a
big boy now I can handle it.
d) Aaaaaarrrrgghhhhh. Read Meyer. Think Robustness - not brittle response.
Jul 15 2004
parent reply "Matthew Wilson" <admin.hat stlsoft.dot.org> writes:
Hmm. That's not good. It might be that I think I'm quoting Meyer, and I'm
quoting someone else instead. For that, apologies to BM (and NG digesters),
and I shall do as you say and certainly plough the bookshelf rather than my
memory henceforth. It's been a long time since I read it, and I've digested
several other things on this issue since, so may well have mixed them in an
insane mental stew.

This potential misquoting aside, I don't resile from my position. If
something's recoverable, then it's an exception. If it's not, then it's a
fault. A fault puts a program into an invalid state, so continuation is, by
definition, undefined. Your post doesn't effectively address that point.
Even for the very simple and accessible example of strcpy() you've failed to
provide a convincing treatment. You say you'd carry on somehow, offering
five options. If I may, I'll heap derision on them now, since we're in
engaging in robust debate.


  1) Try the next string in the vector.


Will the rest of your program logic consider that the "null" string has been
handled correctly? If so, you're program now has an invalid state, and
*anything* might happen henceforth.

Alternatively, if you are writing code that handles this, then how is that
being effected? If you are catching the null pointer before passing to
strcpy, then this does not relate to DbC or strcpy; indeed, you've respected
strcpy()'s contract in that case! <g> If you're catching the hardware null
pointer exception then your code is abusing the semantics of a standard
library function, being probably very inefficient, is anything but
discoverable to maintainers, and not even portable (since not all hardwares
provide null-pointer detection). In short, it's not good.


  2) Decide that the message being processed was invalid. Dump it to log


and

 try the next message.


Dump what to log? The null, or a record of the null?

I'm really not sure what you mean here, so can't offer a rejoinder.


  3) lots of other Robust responses. Meyer. Chapter 7.


Handwaving. Make a point, or don't. (Of course, I may have been doing this
same tactic in this discussion. <g>)


  4) Decide that the stack frame of the current thread must have been
 corrupted somehow. Terminate the thread. Continue the process.


This is *absolutely untenable*!! I defy you to provide a single creditable
source that suggests that termination of a thread can leave a process in a
valid state such that it can continue to live (beyond some non-trivial
amount of final shutdown processing). This is a particularly pernicious myth
that abounds in multi-threading, usually, if I might be so rude, by those
who little understand multi-threading. Operating systems associate system
objects with processes, and not with threads, so the opportunities for
ending up in invalid states - locked handles, abandoned synchronisation
objects, etc etc - are myriad in such a circumstance. Only the termination
of the process can result in an orderly release of system resources.


  5) Decide that the process heap is corrupt. Terminate the process.


Now we're talking! I like this one.


One general point I'd like to make: It seems that you're painting my
argument as "I like process termination, and I don't give a fig about the
consequences to users as long as I can adhere to my DbC purity". But that's
not grokking the advantage that DbC confers. It's quite the opposite in
fact, and it requires a mental leap to see the twist: By requiring early and
severe failure, programs become _massively_ more robust.

For example, I worked on a stock-exchange data caching and delivery
component in 1998, which is running inside what was, and still is, the
busiest transactional website in the southern hemisphere. In six years of
execution, my components have processed 100s of millions of transactions
(involving on God knows how many billions of dollars), and have experienced
0 failures. Not a single one. And it's not that there's some desperate
"handling" of faults in there, taking any extreme measure to keep
processing. It's just that there are no faults. That's what DbC can give.



"Cabal" <cabalN05P4M myrealbox.com> wrote in message
news:cd5kuh$1t7u$1 digitaldaemon.com...

 I've moved the individual chunks of text around so this reads a little
 better.


 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.


 Right. Dig out your copy of Meyer and re-read it. Don't go referencing it
 again until you have. Chapter 7 deals with pre/post conditions and
 contracts and strangely enough it doesn't mention anywhere about a process
 throwing its hands in the air and terrminating itself because something
 didn't happen as expected. He's quite explicit about it - if anything


fails

 for any reason it throws an exception, which should be caught and dealt
 with and the operation possibly retried. Apparently he's quite hot on


this,

 there are a few Eiffel features built into the language for just this
 reason. He goes even further with this logic than I have advocated, and
 states that hardware detected errors can/should be caught and turned into
 software exceptions which are in turn caught and dealt with and the
 relevant operation retried. He even has names for the concept, which you
 might have read once but have obviously forgotten 'Robustness' and
 'Software Fault Tolerance'. Having skimmed the chapter quickly I can't


find

 anywhere were he suggests that termination is an option - certainly not an
 option taken out of the programmers hands and enforced because a library
 misbehaved.



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


 Couldn't agree more, exceptions should certainly be thrown in failure
 situations. I was under the impression this argument was regarding whether
 'someone' (not the programmer writing the code) should be empowered to
 enforce a process termination when particular exception types were
 encountered.


 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.


 Can we clarify definitions here because I get the impression we are


talking

 at slightly cross purposes. I have referred to 'invalid state' as meaning
 that a process is in such a state that continuing correctly is simply not
 possible - you defined it as such earlier. The issue at hand is what
 constitutes an invalid state and how it is detected. Your example above is
 most definitely *not* an example of definitive invalid process state.


Sure,

 95% of programs written in D or whatever else should shut down at this
 point, but the other 5% of mission critical production systems should not
 be forced to terminate because someone, somewhere, somewhen decided on a
 blanket termination policy. You claim to quote Meyer - read chapter 7


again

 and his suggestions for using the EXTERNAL_EXCEPTIONS mechanism to turn
 null dereferences into software exceptions to be caught and worked around.


 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


 Agreed. Where I disagree is D's ability to correctly detect an


unrecoverable

 invalid state. Where I disagree is the decision to have D enforce
 termination in every circumstance.



 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?


 Re-read Meyer. Is that getting boring? I only emphasize you should do this
 because you are misleading others on this mailing list by mis-stating
 Meyer's thoughts on this. I *am* in a position to decide on just how
 recoverable my program state is.


 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.


 You've seen enough of my code to make that judgement? Maybe there's an
 inverse square law in operation here. You check out my 10 - 15 lines code
 on the forum and decide I'm a quality programmer. You read thousands of
 Meyers words of wisdom and decide... well, what did you decide? To forget
 it all?


 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?


 If the code is DbC then I expect to behave according to its contract. If
 that contract is sufficiently well defined to allow me to be confident of
 retrying with different data sets then I damn well want to retry. D should
 *not* have carte blanche to pull my plug! A library written to DbC
 standards should support retries especially well!



 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.


 Repetition begins to grind me down... Meyer, meyer, meyer... Chapter 7.
 Fault tolerance... gasp!


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


 The particular instance may be rot because as stated previously, D would
 never be allowed near a critical system given the current termination
 policy.



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


 DbC has nothing to do with arbitrary program termination. I quite like


DbC.

 I have nothing against it all and would love to come across more code
 written like this. Shall I say it again for effect? DbC is wonderful and
 luvverly and the best thing since sliced bread. Please don't pervert its
 meaning to your dastardly ends.


 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?

 It should cause a SIGSEGV (*nix - sorry).

 What about a null pointer for its destination string?


 It should cause a SIGSEGV (again *nix - don't ask me how windows deals


with

 it)

 How should it indicate error?


 See above. I presume those are the errors you are talking about.

 How should client code of strcpy() detect, and react to, errors?


 Joe Bloggs program to count sheep jumping over fences: let the OS core the
 process and terminate the app. Note: D doesn't have anything to do with
 this either.
 My program monitoring the heart defibrillator (not that that's what I do):
 Intercept (by whatever means are supported) the signal. Turn it into an
 exception to throw to the caller. Caller (however many levels up the stack
 - I don't expect whatever is calling strcpy to be in a position to do much
 intelligent recovery) catches the exception and does whatever it has been
 programmed to do. This could include:
  1) Try the next string in the vector.
  2) Decide that the message being processed was invalid. Dump it to log


and

 try the next message.
  3) lots of other Robust responses. Meyer. Chapter 7.
  4) Decide that the stack frame of the current thread must have been
 corrupted somehow. Terminate the thread. Continue the process.
  5) Decide that the process heap is corrupt. Terminate the process.

 Recap:
 a) We agree (I think) on what an invalid state is.
 b) We disagree on the point at which an invalid state can be detected. You
 are talking in terms of recoverable exceptions whenever you give examples
 of process terminating invalid states.
 c) As a consequence of b) you are advocating brittle termination of


possibly

 perfectly viable processes. The point being that no-one except the person
 programming it can know in advance when it has become invalid.
 d) Don't terminate my process because it does stuff you don't like. I'm a
 big boy now I can handle it.
 d) Aaaaaarrrrgghhhhh. Read Meyer. Think Robustness - not brittle response.
Jul 15 2004
parent reply Cabal <cabalN05P4M myrealbox.com> writes:
 Hmm. That's not good. It might be that I think I'm quoting Meyer, and I'm
 quoting someone else instead. For that, apologies to BM (and NG
 digesters), and I shall do as you say and certainly plough the bookshelf
 rather than my memory henceforth. It's been a long time since I read it,
 and I've digested several other things on this issue since, so may well
 have mixed them in an insane mental stew.



 This potential misquoting aside, I don't resile from my position. If
 something's recoverable, then it's an exception. If it's not, then it's a
 fault. A fault puts a program into an invalid state, so continuation is,
 by definition, undefined. Your post doesn't effectively address that
 point. Even for the very simple and accessible example of strcpy() you've
 failed to provide a convincing treatment. You say you'd carry on somehow,
 offering five options. If I may, I'll heap derision on them now, since
 we're in engaging in robust debate.
 


Christ! I pull your crutch out from under you and you still insist on 
limping on :)


  1) Try the next string in the vector.


 
 Will the rest of your program logic consider that the "null" string has
 been handled correctly? If so, you're program now has an invalid state,
 and *anything* might happen henceforth.
 
 Alternatively, if you are writing code that handles this, then how is that
 being effected? If you are catching the null pointer before passing to
 strcpy, then this does not relate to DbC or strcpy; indeed, you've
 respected strcpy()'s contract in that case! <g> If you're catching the
 hardware null pointer exception then your code is abusing the semantics of
 a standard library function, being probably very inefficient, is anything
 but discoverable to maintainers, and not even portable (since not all
 hardwares provide null-pointer detection). In short, it's not good.
 


The example given reflected the suggestions in Meyer (not the individual
recovery options - just the fact that there could be recovery of some
sort). As he was your main argumentative prop I found it appropriate to
take his suggestion and beat you with it. I can't say I have ever found
cause or desire to catch a hardware signal nor do I intend finding myself
in a situation where it is necessary. Don't try and read too much into it.


  2) Decide that the message being processed was invalid. Dump it to log


 and

 try the next message.


 
 Dump what to log? The null, or a record of the null?
 I'm really not sure what you mean here, so can't offer a rejoinder.


Apologies. In my head I was thinking along the lines of strcpy'ing a field
from a message. I'll be more clear next time.



  3) lots of other Robust responses. Meyer. Chapter 7.


 
 Handwaving. Make a point, or don't. (Of course, I may have been doing this
 same tactic in this discussion. <g>)


Not just hand waving. I had a rubber chicken in each hand and was running
around the room making gibbon noises. Think impact!


  4) Decide that the stack frame of the current thread must have been
 corrupted somehow. Terminate the thread. Continue the process.


 
 This is *absolutely untenable*!! I defy you to provide a single creditable
 source that suggests that termination of a thread can leave a process in a
 valid state such that it can continue to live (beyond some non-trivial
 amount of final shutdown processing). This is a particularly pernicious
 myth that abounds in multi-threading, usually, if I might be so rude, by
 those who little understand multi-threading. Operating systems associate
 system objects with processes, and not with threads, so the opportunities
 for ending up in invalid states - locked handles, abandoned
 synchronisation objects, etc etc - are myriad in such a circumstance. Only
 the termination of the process can result in an orderly release of system
 resources.
 


I have an object on the stack of my thread (or in a TLS variable - take your
pick). This object has been initialised by reading a stream of data. I
perform a strcpy on it and intercept a null ptr exception generated by the
call. This null ptr and the object holding it are totally and utterly
isolated from the rest of the process. I can too make my own mind up about
whether I can terminate this thread. 
Also, before assuming you know everything about threads and threading issues
I suggest you brush up on more than just Windows threads. I am aware (now
that I try to remember) that windows has a particularly broken attitude to
thread termination. Being a *nix guy I was implying the pthreads behaviour
model where thread cancellation with stack rewinding is preferred if you
want your program to continue nicely - and many programs do cancel
individual threads and continue to run perfectly well.



  5) Decide that the process heap is corrupt. Terminate the process.


 
 Now we're talking! I like this one.
 
 
 One general point I'd like to make: It seems that you're painting my
 argument as "I like process termination, and I don't give a fig about the
 consequences to users as long as I can adhere to my DbC purity". But
 that's not grokking the advantage that DbC confers. It's quite the
 opposite in fact, and it requires a mental leap to see the twist: By
 requiring early and severe failure, programs become _massively_ more
 robust.
 
 For example, I worked on a stock-exchange data caching and delivery
 component in 1998, which is running inside what was, and still is, the
 busiest transactional website in the southern hemisphere. In six years of
 execution, my components have processed 100s of millions of transactions
 (involving on God knows how many billions of dollars), and have
 experienced 0 failures. Not a single one. And it's not that there's some
 desperate "handling" of faults in there, taking any extreme measure to
 keep processing. It's just that there are no faults. That's what DbC can
 give.
 


Again, I find myself agreeing with bits of what you say. Yes, it is an known
feature programmed into many robust 'systems' (not programs - no single
program becomes more robust by being killed) that individual components
should fail early and noisily. Every single program I have written or being
involved with writing for the last twelve years has had this 'feature'. The
key point is that this was chosen as the way to do it. At any point we
could have said "No! We'll catch X or Y and attempt to recover in this
particular instance or that particular instance." There would never have
been a little voice in the pits of the library saying "Oooo no! you can't
do that. You've got to die!". Also, you seem to imbuing DbC with magical
properties to prevent failures (probably not your explicit intent but it
could be read that way by the uninformed). DbC specifies pre/post
conditions and invariants and exceptions on violation of these - nowhere is
it implicit or explicit that the only option is to terminate the program.
That is a choice for the programmer.

The crux of this argument is choice. You advocate enforced process
termination in all cases irrelevant of the merits in individual cases for
recovery.  It appears to me that you have ideas about what can be done in a
process and that these set ideas are limited to your experience (probably
on windows given the tirade above regarding thread termination and the
windows assumptions built into it). My experience is with *nix where we
can, if we choose, implement various recovery procedures safely and have a
process continue after a 'failure' (your failure, my exception). Please
don't mistake what you consider to be 'the one true way' with the actuality
of the rest of the world at large. 

I'll say it again - in another way. Please don't make the mistake of forcing
me to conform to what you consider to be the only way to do things. Just
because early termination can be a good thing does not make it the only
thing possible.
Jul 15 2004
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Cabal" <cabalN05P4M myrealbox.com> wrote in message
news:cd6651$25ur$1 digitaldaemon.com...

 Hmm. That's not good. It might be that I think I'm quoting Meyer, and I'm
 quoting someone else instead. For that, apologies to BM (and NG
 digesters), and I shall do as you say and certainly plough the bookshelf
 rather than my memory henceforth. It's been a long time since I read it,
 and I've digested several other things on this issue since, so may well
 have mixed them in an insane mental stew.



 This potential misquoting aside, I don't resile from my position. If
 something's recoverable, then it's an exception. If it's not, then it's a
 fault. A fault puts a program into an invalid state, so continuation is,
 by definition, undefined. Your post doesn't effectively address that
 point. Even for the very simple and accessible example of strcpy() you've
 failed to provide a convincing treatment. You say you'd carry on somehow,
 offering five options. If I may, I'll heap derision on them now, since
 we're in engaging in robust debate.


 Christ! I pull your crutch out from under you and you still insist on
 limping on :)


  1) Try the next string in the vector.


 Will the rest of your program logic consider that the "null" string has
 been handled correctly? If so, you're program now has an invalid state,
 and *anything* might happen henceforth.

 Alternatively, if you are writing code that handles this, then how is that
 being effected? If you are catching the null pointer before passing to
 strcpy, then this does not relate to DbC or strcpy; indeed, you've
 respected strcpy()'s contract in that case! <g> If you're catching the
 hardware null pointer exception then your code is abusing the semantics of
 a standard library function, being probably very inefficient, is anything
 but discoverable to maintainers, and not even portable (since not all
 hardwares provide null-pointer detection). In short, it's not good.


 The example given reflected the suggestions in Meyer (not the individual
 recovery options - just the fact that there could be recovery of some
 sort). As he was your main argumentative prop I found it appropriate to
 take his suggestion and beat you with it. I can't say I have ever found
 cause or desire to catch a hardware signal nor do I intend finding myself
 in a situation where it is necessary. Don't try and read too much into it.


I don't get the purpose of this paragraph. Is it just a sufficient quantity of
words to mask the fact that you won't, or can't, address the simple example of
strcpy()?


  2) Decide that the message being processed was invalid. Dump it to log


 and

 try the next message.


 Dump what to log? The null, or a record of the null?
 I'm really not sure what you mean here, so can't offer a rejoinder.


 Apologies. In my head I was thinking along the lines of strcpy'ing a field
 from a message. I'll be more clear next time.



  3) lots of other Robust responses. Meyer. Chapter 7.


 Handwaving. Make a point, or don't. (Of course, I may have been doing this
 same tactic in this discussion. <g>)


 Not just hand waving. I had a rubber chicken in each hand and was running
 around the room making gibbon noises. Think impact!


  4) Decide that the stack frame of the current thread must have been
 corrupted somehow. Terminate the thread. Continue the process.


 This is *absolutely untenable*!! I defy you to provide a single creditable
 source that suggests that termination of a thread can leave a process in a
 valid state such that it can continue to live (beyond some non-trivial
 amount of final shutdown processing). This is a particularly pernicious
 myth that abounds in multi-threading, usually, if I might be so rude, by
 those who little understand multi-threading. Operating systems associate
 system objects with processes, and not with threads, so the opportunities
 for ending up in invalid states - locked handles, abandoned
 synchronisation objects, etc etc - are myriad in such a circumstance. Only
 the termination of the process can result in an orderly release of system
 resources.


 I have an object on the stack of my thread (or in a TLS variable - take your
 pick). This object has been initialised by reading a stream of data. I
 perform a strcpy on it and intercept a null ptr exception generated by the
 call. This null ptr and the object holding it are totally and utterly
 isolated from the rest of the process. I can too make my own mind up about
 whether I can terminate this thread.
 Also, before assuming you know everything about threads and threading issues
 I suggest you brush up on more than just Windows threads.


Not sure if you're using "you" to mean me, or to mean "one". If you mean me, I
certainly don't think I know everything about threading on either Win32 or UNIX,
any more than I think I know everythng about anything. Only an idiot does that.
But I have experience building very robust systems with both Win32 threads and
PThreads.

Before we steam ahead on this, maybe when you said "Terminate the thread" you
meant, have the the thread exit / return. If that's the case (i) we're violently
agreeing, and (ii) you should have said what you meant. If you do indeed mean
terminate - i.e. to halt the thread, remove it from the scheduler and discard
its
memory - then I stand by my comments.


 I am aware (now
 that I try to remember) that windows has a particularly broken attitude to
 thread termination. Being a *nix guy I was implying the pthreads behaviour
 model where thread cancellation with stack rewinding is preferred if you
 want your program to continue nicely - and many programs do cancel
 individual threads and continue to run perfectly well.


And this does indeed seem to indicate you meant exit, or return from. In which
case you should have spoken precisely, and saved us both some time.


  5) Decide that the process heap is corrupt. Terminate the process.


 Now we're talking! I like this one.


 One general point I'd like to make: It seems that you're painting my
 argument as "I like process termination, and I don't give a fig about the
 consequences to users as long as I can adhere to my DbC purity". But
 that's not grokking the advantage that DbC confers. It's quite the
 opposite in fact, and it requires a mental leap to see the twist: By
 requiring early and severe failure, programs become _massively_ more
 robust.

 For example, I worked on a stock-exchange data caching and delivery
 component in 1998, which is running inside what was, and still is, the
 busiest transactional website in the southern hemisphere. In six years of
 execution, my components have processed 100s of millions of transactions
 (involving on God knows how many billions of dollars), and have
 experienced 0 failures. Not a single one. And it's not that there's some
 desperate "handling" of faults in there, taking any extreme measure to
 keep processing. It's just that there are no faults. That's what DbC can
 give.


 Again, I find myself agreeing with bits of what you say. Yes, it is an known
 feature programmed into many robust 'systems' (not programs - no single
 program becomes more robust by being killed) that individual components
 should fail early and noisily. Every single program I have written or being
 involved with writing for the last twelve years has had this 'feature'. The
 key point is that this was chosen as the way to do it. At any point we
 could have said "No! We'll catch X or Y and attempt to recover in this
 particular instance or that particular instance." There would never have
 been a little voice in the pits of the library saying "Oooo no! you can't
 do that. You've got to die!". Also, you seem to imbuing DbC with magical
 properties to prevent failures (probably not your explicit intent but it
 could be read that way by the uninformed). DbC specifies pre/post
 conditions and invariants and exceptions on violation of these - nowhere is
 it implicit or explicit that the only option is to terminate the program.
 That is a choice for the programmer.

 The crux of this argument is choice. You advocate enforced process
 termination in all cases irrelevant of the merits in individual cases for
 recovery.  It appears to me that you have ideas about what can be done in a
 process and that these set ideas are limited to your experience (probably
 on windows given the tirade above regarding thread termination and the
 windows assumptions built into it). My experience is with *nix where we
 can, if we choose, implement various recovery procedures safely and have a
 process continue after a 'failure' (your failure, my exception).


Man, how many times do I have to say it: if it's recoverable, it's an exception.
If it's not, it's an error (or fault, for a less ambiguous term). You keep
implying that I'm stipulating that a process should fail from a recoverable
error. I am not.


 Please
 don't mistake what you consider to be 'the one true way' with the actuality
 of the rest of the world at large.

 I'll say it again - in another way. Please don't make the mistake of forcing
 me to conform to what you consider to be the only way to do things. Just
 because early termination can be a good thing does not make it the only
 thing possible.


I simply remain a blank page, waiting for someone to write in it how a process
can validly proceed once it has been rendered in an invalid (or undefined)
state.
Please scribble away in something legible.

Since we're casting aspersions about each others knowledge / POVs on scant
evidence, I shall comment that to me it seems you still don't "get" the whole
enforcement thing. By early enforcement of failure, one avoids failure. That,
along with the undefined behaviour of faulted processes, are the two sides of my
argument. But we seem to be failing to connect in either regard, and I can't
think of any other ways to say them, so I'll shut my trap.

:)
Jul 15 2004
parent reply Cabal <cabalN05P4M myrealbox.com> writes:
Okay. Clean slate (apart from mutterings about obtuse pedantic buggers)

These are the points argued so far:

1)
You: When a hardware exception occurs your process is by definition in an
invalid state and must exit rather swiftly. No ifs, no buts, no reprieve.
Me: Not the case. Zero page accesses, divide by 0 can be recovered from.
2)
You: DbC violations are unrecoverable. You process is by definition in an
invalid state and must exit rather swiftly. etc etc. 
Me: Not the case. blah blah.

If I have mis-represented you please correct me. 

Everything else appears to be rehashing the above one way or another or
impuning the others knowledge or ability. And all because there is a
mis-feature in D which states that Error and it's derivatives are
non-recoverable. You don't question the validity of that assumption - I do.
It's that simple and everything in this thread follows logically on both
sides of the argument.

Please take note that all along I have acknowledged that my 'examples' are
contrived and I haven't found need or desire to implement them, they were
given in response to the examples for non-recoverability you presented to
make your case. They exist purely for the sake of demonstrating that
process termination is not the one and only option and should not be
foisted on everyone just because it's the desirable default option in most
cases.
Jul 15 2004
next sibling parent reply Cabal <cabalN05P4M myrealbox.com> writes:
And do none of you morbid buggers reading this thread know anything about
template specialisations and why alias's screw them up? If you do I'd
appreciate you looking at the thread "Template specialisations and
'alias'". Move along now. Nothing to see here. :)

Thx
Jul 15 2004
parent reply "Matthew Wilson" <admin.hat stlsoft.dot.org> writes:
"Cabal" <cabalN05P4M myrealbox.com> wrote in message
news:cd6b0k$2803$2 digitaldaemon.com...

 And do none of you morbid buggers reading this thread know anything about
 template specialisations and why alias's screw them up? If you do I'd
 appreciate you looking at the thread "Template specialisations and
 'alias'". Move along now. Nothing to see here. :)


See my various posts on the NG about using the "hack" technique to get the
alias'd types.

He he, nice to be on the same team for a mo, is it not? :-)
Jul 15 2004
parent Cabal <cabalN05P4M myrealbox.com> writes:
Matthew Wilson wrote:


 
 "Cabal" <cabalN05P4M myrealbox.com> wrote in message
 news:cd6b0k$2803$2 digitaldaemon.com...

 And do none of you morbid buggers reading this thread know anything about
 template specialisations and why alias's screw them up? If you do I'd
 appreciate you looking at the thread "Template specialisations and
 'alias'". Move along now. Nothing to see here. :)


 
 See my various posts on the NG about using the "hack" technique to get the
 alias'd types.
 
 He he, nice to be on the same team for a mo, is it not? :-)


I wish I could find your posts to check them out. Nothing comes up with
template, alias or hack in the subject. And the group isn't on google yet
so I can't search bodies - maybe I need a different reader.
Jul 16 2004
prev sibling parent reply "Matthew Wilson" <admin.hat stlsoft.dot.org> writes:
"Cabal" <cabalN05P4M myrealbox.com> wrote in message
news:cd6arm$2803$1 digitaldaemon.com...

 Okay. Clean slate (apart from mutterings about obtuse pedantic buggers)

 These are the points argued so far:

 1)
 You: When a hardware exception occurs your process is by definition in an
 invalid state and must exit rather swiftly. No ifs, no buts, no reprieve.


Didn't say hardware exceptions. (Or if I did, I didn't necessarily mean it).

Indexing off the end of an array would also put the program into an invalid
state, but would be unlikely to result in hardware exception (except where
it's snug against an uncommitted page).


 Me: Not the case. Zero page accesses, divide by 0 can be recovered from.
 2)
 You: DbC violations are unrecoverable. You process is by definition in an
 invalid state and must exit rather swiftly. etc etc.
 Me: Not the case. blah blah.


Correct


 If I have mis-represented you please correct me.

 Everything else appears to be rehashing the above one way or another or
 impuning the others knowledge or ability. And all because there is a
 mis-feature in D which states that Error and it's derivatives are
 non-recoverable. You don't question the validity of that assumption - I


do.

I don't think you're right here. I've not developed my opinions on this
issue because of some little-visited comment in object.d. Is that what
you're implying? (I'd have to have had a time machine, for a kick off!)


 It's that simple and everything in this thread follows logically on both
 sides of the argument.

 Please take note that all along I have acknowledged that my 'examples' are
 contrived and I haven't found need or desire to implement them, they were
 given in response to the examples for non-recoverability you presented to
 make your case. They exist purely for the sake of demonstrating that
 process termination is not the one and only option and should not be
 foisted on everyone just because it's the desirable default option in most
 cases.


As was discussed a short while ago, the nuclear reactor example is the
perfect example of what I'm talking about. If you're still interested in
this debate, please respond to that argument, since I can't imagine being
able to come up with a more convincing example.
Jul 15 2004
parent reply Cabal <cabalN05P4M myrealbox.com> writes:
Once more unto the breach dear friends....


 These are the points argued so far:

 1)
 You: When a hardware exception occurs your process is by definition in an
 invalid state and must exit rather swiftly. No ifs, no buts, no reprieve.


 
 Didn't say hardware exceptions. (Or if I did, I didn't necessarily mean
 it).


Apologies for assuming more knowledge on your behalf than you had - when
someone talks about the behaviour expected from passing null's to strcpy I
automatically assume they have an inkling that they are going to get
hardware exceptions/faults.


 Indexing off the end of an array would also put the program into an
 invalid state, but would be unlikely to result in hardware exception
 (except where it's snug against an uncommitted page).


Core paradigm mismatch alert! Hello we meet again. Regardless of hardware
exceptions, accessing [I'll presume read as it fits my part of the argument
and you seem to be talking about any access) beyond the range of an array
does *not* put anything anywhere, least of all a process into an invalid
state. It implies that something somewhere has used an inappropriate value
- nothing more. It's entirely possible to continue execution - there is
nothing intrinsically invalidating about such accesses. Am I repeating
myself?


 Me: Not the case. Zero page accesses, divide by 0 can be recovered from.
 2)
 You: DbC violations are unrecoverable. You process is by definition in an
 invalid state and must exit rather swiftly. etc etc.
 Me: Not the case. blah blah.


 
 Correct


Me: No its not!
You: Yes it is!
Me: No its not!
You: He's behind you!

Panto season might well be here before this one is resolved.


 If I have mis-represented you please correct me.

 Everything else appears to be rehashing the above one way or another or
 impuning the others knowledge or ability. And all because there is a
 mis-feature in D which states that Error and it's derivatives are
 non-recoverable. You don't question the validity of that assumption - I


 do.
 
 I don't think you're right here. I've not developed my opinions on this
 issue because of some little-visited comment in object.d. Is that what
 you're implying? (I'd have to have had a time machine, for a kick off!)


I can't even be bothered to go look at object.d now that you've told me
there's a comment in there. I'm working entirely off your comments in the
thread above. You started this thread with concerns about which exception
conditions were Exception derived and which were Error derived. Not the
fact that Exceptions were catchable and Error supposedly not.
  <Quote>(Remember, Error is non-recoverable.)</Quote>
I certainly based my commentary on this statement and what you've said
since. I think that your arguments are entirely logical and well thought
out/through if we assume your basic premise is correct. Unfortunately you
are wrong down at the very bottom of your pile of building blocks. 


 

 It's that simple and everything in this thread follows logically on both
 sides of the argument.

 Please take note that all along I have acknowledged that my 'examples'
 are contrived and I haven't found need or desire to implement them, they
 were given in response to the examples for non-recoverability you
 presented to make your case. They exist purely for the sake of
 demonstrating that process termination is not the one and only option and
 should not be foisted on everyone just because it's the desirable default
 option in most cases.


 
 As was discussed a short while ago, the nuclear reactor example is the
 perfect example of what I'm talking about. If you're still interested in
 this debate, please respond to that argument, since I can't imagine being
 able to come up with a more convincing example.


My keyboard appears to be getting clogged up with all the hair I'm pulling
out here! How many large and small scale examples do you need? Yes, they
are all contrived. Acknowledged at the point of contrivance. I am not
trying to present real world cases - I am trying to make sure that you
realise that there could be cases out there in the real world which do not
match your nice, tidy and limited development world view. You are trying to
constrain D to your particular requirements. Stop it!

btw - you do realise that even Walter has effectively agreed with me on your
"Demunging erroneous terminological nomenclatural obfuscations" thread
don't you? Whistling in the wind anyone?
Jul 16 2004
parent "Matthew Wilson" <admin.hat stlsoft.dot.org> writes:
I've said all I'm saying on this on the nuclear power plant issue. If you've
anything concrete to say about that example, please do so. Otherwise, you're
wasting your keystrokes, because I've stopped reading.

"Cabal" <cabalN05P4M myrealbox.com> wrote in message
news:cd86t8$1sh$1 digitaldaemon.com...

 Once more unto the breach dear friends....


 These are the points argued so far:

 1)
 You: When a hardware exception occurs your process is by definition in






an

 invalid state and must exit rather swiftly. No ifs, no buts, no






reprieve.

 Didn't say hardware exceptions. (Or if I did, I didn't necessarily mean
 it).


 Apologies for assuming more knowledge on your behalf than you had - when
 someone talks about the behaviour expected from passing null's to strcpy I
 automatically assume they have an inkling that they are going to get
 hardware exceptions/faults.


 Indexing off the end of an array would also put the program into an
 invalid state, but would be unlikely to result in hardware exception
 (except where it's snug against an uncommitted page).


 Core paradigm mismatch alert! Hello we meet again. Regardless of hardware
 exceptions, accessing [I'll presume read as it fits my part of the


argument

 and you seem to be talking about any access) beyond the range of an array
 does *not* put anything anywhere, least of all a process into an invalid
 state. It implies that something somewhere has used an inappropriate value
 - nothing more. It's entirely possible to continue execution - there is
 nothing intrinsically invalidating about such accesses. Am I repeating
 myself?


 Me: Not the case. Zero page accesses, divide by 0 can be recovered






from.

 2)
 You: DbC violations are unrecoverable. You process is by definition in






an

 invalid state and must exit rather swiftly. etc etc.
 Me: Not the case. blah blah.


 Correct


 Me: No its not!
 You: Yes it is!
 Me: No its not!
 You: He's behind you!

 Panto season might well be here before this one is resolved.


 If I have mis-represented you please correct me.

 Everything else appears to be rehashing the above one way or another or
 impuning the others knowledge or ability. And all because there is a
 mis-feature in D which states that Error and it's derivatives are
 non-recoverable. You don't question the validity of that assumption - I


 do.

 I don't think you're right here. I've not developed my opinions on this
 issue because of some little-visited comment in object.d. Is that what
 you're implying? (I'd have to have had a time machine, for a kick off!)


 I can't even be bothered to go look at object.d now that you've told me
 there's a comment in there. I'm working entirely off your comments in the
 thread above. You started this thread with concerns about which exception
 conditions were Exception derived and which were Error derived. Not the
 fact that Exceptions were catchable and Error supposedly not.
   <Quote>(Remember, Error is non-recoverable.)</Quote>
 I certainly based my commentary on this statement and what you've said
 since. I think that your arguments are entirely logical and well thought
 out/through if we assume your basic premise is correct. Unfortunately you
 are wrong down at the very bottom of your pile of building blocks.


 It's that simple and everything in this thread follows logically on






both

 sides of the argument.

 Please take note that all along I have acknowledged that my 'examples'
 are contrived and I haven't found need or desire to implement them,






they

 were given in response to the examples for non-recoverability you
 presented to make your case. They exist purely for the sake of
 demonstrating that process termination is not the one and only option






and

 should not be foisted on everyone just because it's the desirable






default

 option in most cases.


 As was discussed a short while ago, the nuclear reactor example is the
 perfect example of what I'm talking about. If you're still interested in
 this debate, please respond to that argument, since I can't imagine




being

 able to come up with a more convincing example.


 My keyboard appears to be getting clogged up with all the hair I'm pulling
 out here! How many large and small scale examples do you need? Yes, they
 are all contrived. Acknowledged at the point of contrivance. I am not
 trying to present real world cases - I am trying to make sure that you
 realise that there could be cases out there in the real world which do not
 match your nice, tidy and limited development world view. You are trying


to

 constrain D to your particular requirements. Stop it!

 btw - you do realise that even Walter has effectively agreed with me on


your

 "Demunging erroneous terminological nomenclatural obfuscations" thread
 don't you? Whistling in the wind anyone?
Jul 16 2004
prev sibling parent Charlie <Charlie_member pathlink.com> writes:
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.
Jul 14 2004
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
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?


Sean
Jul 14 2004
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"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.
Jul 14 2004
parent Sean Kelly <sean f4.ca> writes:
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
Jul 14 2004