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