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)

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

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cd366u$1glp$1@digitaldaemon.com...
> In article <cd34hk$1dml$1@digitaldaemon.com>, Matthew says...
>
> I agree with most of what you said, apart from this bit...
>
> >(Remember, Error is
> >non-recoverable.)
>
> Says who? Why on EARTH would you want ANYTHING to be unrecoverable?

That's kind of the definition of an error.

btw, I'm starting to be won over by the power of your shouting (masking the gaps
in your arguments).

> Say I write a big, multi-threaded server app, and ONE little sub-thread throws an Error with a capital E. I can recover from that.

No you can't. The error has rendered your program in an invalid state. From that point on you have no (I'm tempted to shout here), I repeat _no_, guarantees as to any future behaviour.

> For example, I write some rival to Microsoft Word. The User is editing ten documents at once. ONE of them throws an error. Why do I have to shut down the other nine?

Because your program might do absolutely anything if you continue. You might - as I've done in the past in just such a circumstance with Dev Studio - try and save a few last changes to one or more of those documents and lose the entire file, not just the changes.

> I don't agree that Errors should be non-recoverable.

That's evident, and you're perfectly within your rights to think whatever you like. I don't think that Australians are good at sport, or that I'm going to loose my hair and develop a paunch.

> If I can deal with it
> safely, I should be allowed so to do.

If you can deal with it safely, then it's not an error.

> On the agreement front, though, a nice well document heirarchy of errors and exceptions would be great.
>
> Where does OutOfMemory fit into this hierarchy? (And I *definitely* want to be able to recover from that!).

OutOfMemory is an exception, not an error, so you can recover from it. (Of course, you might be catching another pretty soon after, but that's another matte r.)

In terms of where it fits, until and unless we get a ResourceException sub-tree, I'd say it can just live under Exception.

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

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)

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

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.

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

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

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