Thread overview | |||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
July 14, 2004 Standard exceptions - some disturbing observations | ||||
---|---|---|---|---|
| ||||
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) |
July 14, 2004 Re: Standard exceptions - some disturbing observations | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | 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 |
July 14, 2004 Re: Standard exceptions - some disturbing observations | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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. |
July 14, 2004 Re: Standard exceptions - some disturbing observations | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | 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) > > > |
July 14, 2004 Re: Standard exceptions - some disturbing observations | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | 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)
|
July 14, 2004 Re: Standard exceptions - some disturbing observations | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | 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
|
July 14, 2004 Re: Standard exceptions - some disturbing observations | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | 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. |
July 14, 2004 Re: Standard exceptions - some disturbing observations | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | 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.
>
>
>
>
>
|
July 14, 2004 Re: Standard exceptions - some disturbing observations | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | 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 |
July 14, 2004 Re: Standard exceptions - some disturbing observations | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Reimer | "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. |
Copyright © 1999-2021 by the D Language Foundation