www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - standardize Error and Exception subclassing

reply "Ben Hinkle" <bhinkle mathworks.com> writes:
Matthew brought this up before, but can we get some sanity in the
Error/Exception hierarchy (both in phobos and user code)?

I looked at some user libraries like mango and deimos and they use
Exceptions. I have been subclassing Exception without even thinking about it
because I am so used to Java's scheme. I'm going to redo all my code to use
Error subclasses and I think we as a community need to get some consistency.
It will be annoying to search-replace the names but the alternative is a
mess.

From a previous post Matthew made here is the list of Error subclasses and
Exception subclasses in phobos:

Exception
    Base64Exception
    Base64CharException
    FileException
    ExeModuleException
    ModuleCtorError
    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
        FormatError
        RegExpError
        StreamError
            ReadError
            WriteError
            SeekError
            StreamFileError
                OpenError
                CreateError
        ThreadError
        URIerror
        UtfError

SwitchError (derived from Object)


This list might be slightly out of date by now but it probably is still
fairly accurate. In keeping with what looks like D's convention, I propose
- all the non-Error subclasses except ModuleCtorError be made subclasses of
Error.
- the ModuleCtorError class should be renamed ModuleCtorException.
- objects thrown from user libraries should subclass Error instead of
Exception

If it would be possible I'd also like to remove or rename Exception so that

Throwable is the root of the Error/Exception tree. Maybe D could have
Throwable, Error:Throwable and FatalError:Throwable and we could get rid of
Exception to avoid confusion with Error.

-Ben
Aug 24 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
The idea is that recoverable errors should derive from Exception, and
non-recoverable from Error. So I think the list here needs revising.

"Ben Hinkle" <bhinkle mathworks.com> wrote in message
news:cgfm68$v0g$1 digitaldaemon.com...
 Matthew brought this up before, but can we get some sanity in the
 Error/Exception hierarchy (both in phobos and user code)?

 I looked at some user libraries like mango and deimos and they use
 Exceptions. I have been subclassing Exception without even thinking about
it
 because I am so used to Java's scheme. I'm going to redo all my code to
use
 Error subclasses and I think we as a community need to get some
consistency.
 It will be annoying to search-replace the names but the alternative is a
 mess.

 From a previous post Matthew made here is the list of Error subclasses and
 Exception subclasses in phobos:

 Exception
     Base64Exception
     Base64CharException
     FileException
     ExeModuleException
     ModuleCtorError
     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
         FormatError
         RegExpError
         StreamError
             ReadError
             WriteError
             SeekError
             StreamFileError
                 OpenError
                 CreateError
         ThreadError
         URIerror
         UtfError

 SwitchError (derived from Object)


 This list might be slightly out of date by now but it probably is still
 fairly accurate. In keeping with what looks like D's convention, I propose
 - all the non-Error subclasses except ModuleCtorError be made subclasses
of
 Error.
 - the ModuleCtorError class should be renamed ModuleCtorException.
 - objects thrown from user libraries should subclass Error instead of
 Exception

 If it would be possible I'd also like to remove or rename Exception so
that

 Throwable is the root of the Error/Exception tree. Maybe D could have
 Throwable, Error:Throwable and FatalError:Throwable and we could get rid
of
 Exception to avoid confusion with Error.

 -Ben
Aug 24 2004
next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
whew. Then then std.stream changes will stay (presumably). I think the
documentation about errors needs updating, too, since it doesn't mention the
Exception class, only Error.

"Walter" <newshound digitalmars.com> wrote in message
news:cgg2cc$1518$2 digitaldaemon.com...
 The idea is that recoverable errors should derive from Exception, and
 non-recoverable from Error. So I think the list here needs revising.

 "Ben Hinkle" <bhinkle mathworks.com> wrote in message
 news:cgfm68$v0g$1 digitaldaemon.com...
 Matthew brought this up before, but can we get some sanity in the
 Error/Exception hierarchy (both in phobos and user code)?

 I looked at some user libraries like mango and deimos and they use
 Exceptions. I have been subclassing Exception without even thinking
about
 it
 because I am so used to Java's scheme. I'm going to redo all my code to
use
 Error subclasses and I think we as a community need to get some
consistency.
 It will be annoying to search-replace the names but the alternative is a
 mess.

 From a previous post Matthew made here is the list of Error subclasses
and
 Exception subclasses in phobos:

 Exception
     Base64Exception
     Base64CharException
     FileException
     ExeModuleException
     ModuleCtorError
     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
         FormatError
         RegExpError
         StreamError
             ReadError
             WriteError
             SeekError
             StreamFileError
                 OpenError
                 CreateError
         ThreadError
         URIerror
         UtfError

 SwitchError (derived from Object)


 This list might be slightly out of date by now but it probably is still
 fairly accurate. In keeping with what looks like D's convention, I
propose
 - all the non-Error subclasses except ModuleCtorError be made subclasses
of
 Error.
 - the ModuleCtorError class should be renamed ModuleCtorException.
 - objects thrown from user libraries should subclass Error instead of
 Exception

 If it would be possible I'd also like to remove or rename Exception so
that

Java
 Throwable is the root of the Error/Exception tree. Maybe D could have
 Throwable, Error:Throwable and FatalError:Throwable and we could get rid
of
 Exception to avoid confusion with Error.

 -Ben
Aug 24 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
Something else that seems odd and has been mentioned before is that Error 
derives from Exception.

This seems backwards to me, I know it's a small point, but I think it 
would make more sense if Error were the base class and Exception the child 
class.

Given the idea is that an Exception is recoverable, then Error derived 
 from Exception removes this 'recoverable' property, which goes against the 
OO concept of child classes always adding to base classes.

I know the 'recoverable' property is actually a non existant, non concrete 
thing and that you could still try to recover after catching an Error, 
but.. it just seems wrong.

Regan

On Tue, 24 Aug 2004 15:43:15 -0400, Ben Hinkle <bhinkle mathworks.com> 
wrote:

 whew. Then then std.stream changes will stay (presumably). I think the
 documentation about errors needs updating, too, since it doesn't mention 
 the
 Exception class, only Error.

 "Walter" <newshound digitalmars.com> wrote in message
 news:cgg2cc$1518$2 digitaldaemon.com...
 The idea is that recoverable errors should derive from Exception, and
 non-recoverable from Error. So I think the list here needs revising.

 "Ben Hinkle" <bhinkle mathworks.com> wrote in message
 news:cgfm68$v0g$1 digitaldaemon.com...
 Matthew brought this up before, but can we get some sanity in the
 Error/Exception hierarchy (both in phobos and user code)?

 I looked at some user libraries like mango and deimos and they use
 Exceptions. I have been subclassing Exception without even thinking
about
 it
 because I am so used to Java's scheme. I'm going to redo all my code 
to use
 Error subclasses and I think we as a community need to get some
consistency.
 It will be annoying to search-replace the names but the alternative 
is a
 mess.

 From a previous post Matthew made here is the list of Error subclasses
and
 Exception subclasses in phobos:

 Exception
     Base64Exception
     Base64CharException
     FileException
     ExeModuleException
     ModuleCtorError
     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
         FormatError
         RegExpError
         StreamError
             ReadError
             WriteError
             SeekError
             StreamFileError
                 OpenError
                 CreateError
         ThreadError
         URIerror
         UtfError

 SwitchError (derived from Object)


 This list might be slightly out of date by now but it probably is 
still
 fairly accurate. In keeping with what looks like D's convention, I
propose
 - all the non-Error subclasses except ModuleCtorError be made 
subclasses of
 Error.
 - the ModuleCtorError class should be renamed ModuleCtorException.
 - objects thrown from user libraries should subclass Error instead of
 Exception

 If it would be possible I'd also like to remove or rename Exception so
that

Java
 Throwable is the root of the Error/Exception tree. Maybe D could have
 Throwable, Error:Throwable and FatalError:Throwable and we could get 
rid of
 Exception to avoid confusion with Error.

 -Ben
-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 24 2004
next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
They should both derive from Throwable, and no user classes should be allowed
to derive from Throwable.

There's no excuse for the current state of the exception hierarchy (other than
Walter's workload, I supposed). *Please*
can we have it sorted soon, before people compound the current mess with even
more blunders.


"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsc9jbfq75a2sq9 digitalmars.com...
 Something else that seems odd and has been mentioned before is that Error
 derives from Exception.

 This seems backwards to me, I know it's a small point, but I think it
 would make more sense if Error were the base class and Exception the child
 class.

 Given the idea is that an Exception is recoverable, then Error derived
  from Exception removes this 'recoverable' property, which goes against the
 OO concept of child classes always adding to base classes.

 I know the 'recoverable' property is actually a non existant, non concrete
 thing and that you could still try to recover after catching an Error,
 but.. it just seems wrong.

 Regan

 On Tue, 24 Aug 2004 15:43:15 -0400, Ben Hinkle <bhinkle mathworks.com>
 wrote:

 whew. Then then std.stream changes will stay (presumably). I think the
 documentation about errors needs updating, too, since it doesn't mention
 the
 Exception class, only Error.

 "Walter" <newshound digitalmars.com> wrote in message
 news:cgg2cc$1518$2 digitaldaemon.com...
 The idea is that recoverable errors should derive from Exception, and
 non-recoverable from Error. So I think the list here needs revising.

 "Ben Hinkle" <bhinkle mathworks.com> wrote in message
 news:cgfm68$v0g$1 digitaldaemon.com...
 Matthew brought this up before, but can we get some sanity in the
 Error/Exception hierarchy (both in phobos and user code)?

 I looked at some user libraries like mango and deimos and they use
 Exceptions. I have been subclassing Exception without even thinking
about
 it
 because I am so used to Java's scheme. I'm going to redo all my code
to use
 Error subclasses and I think we as a community need to get some
consistency.
 It will be annoying to search-replace the names but the alternative
is a
 mess.

 From a previous post Matthew made here is the list of Error subclasses
and
 Exception subclasses in phobos:

 Exception
     Base64Exception
     Base64CharException
     FileException
     ExeModuleException
     ModuleCtorError
     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
         FormatError
         RegExpError
         StreamError
             ReadError
             WriteError
             SeekError
             StreamFileError
                 OpenError
                 CreateError
         ThreadError
         URIerror
         UtfError

 SwitchError (derived from Object)


 This list might be slightly out of date by now but it probably is
still
 fairly accurate. In keeping with what looks like D's convention, I
propose
 - all the non-Error subclasses except ModuleCtorError be made
subclasses of
 Error.
 - the ModuleCtorError class should be renamed ModuleCtorException.
 - objects thrown from user libraries should subclass Error instead of
 Exception

 If it would be possible I'd also like to remove or rename Exception so
that

Java
 Throwable is the root of the Error/Exception tree. Maybe D could have
 Throwable, Error:Throwable and FatalError:Throwable and we could get
rid of
 Exception to avoid confusion with Error.

 -Ben
-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 24 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Wed, 25 Aug 2004 12:06:22 +1000, Matthew <admin.hat stlsoft.dot.org> 
wrote:
 They should both derive from Throwable, and no user classes should be 
 allowed to derive from Throwable.
Given that you can, and may want to catch Errors as well as Exceptions then one should derive from the other, right? otherwise what does the catch block look like?
 There's no excuse for the current state of the exception hierarchy 
 (other than Walter's workload, I supposed). *Please*
 can we have it sorted soon, before people compound the current mess with 
 even more blunders.
I agree, it needs to be fixed ASAP. Regan
 "Regan Heath" <regan netwin.co.nz> wrote in message 
 news:opsc9jbfq75a2sq9 digitalmars.com...
 Something else that seems odd and has been mentioned before is that 
 Error
 derives from Exception.

 This seems backwards to me, I know it's a small point, but I think it
 would make more sense if Error were the base class and Exception the 
 child
 class.

 Given the idea is that an Exception is recoverable, then Error derived
  from Exception removes this 'recoverable' property, which goes against 
 the
 OO concept of child classes always adding to base classes.

 I know the 'recoverable' property is actually a non existant, non 
 concrete
 thing and that you could still try to recover after catching an Error,
 but.. it just seems wrong.

 Regan

 On Tue, 24 Aug 2004 15:43:15 -0400, Ben Hinkle <bhinkle mathworks.com>
 wrote:

 whew. Then then std.stream changes will stay (presumably). I think the
 documentation about errors needs updating, too, since it doesn't 
mention
 the
 Exception class, only Error.

 "Walter" <newshound digitalmars.com> wrote in message
 news:cgg2cc$1518$2 digitaldaemon.com...
 The idea is that recoverable errors should derive from Exception, and
 non-recoverable from Error. So I think the list here needs revising.

 "Ben Hinkle" <bhinkle mathworks.com> wrote in message
 news:cgfm68$v0g$1 digitaldaemon.com...
 Matthew brought this up before, but can we get some sanity in the
 Error/Exception hierarchy (both in phobos and user code)?

 I looked at some user libraries like mango and deimos and they use
 Exceptions. I have been subclassing Exception without even thinking
about
 it
 because I am so used to Java's scheme. I'm going to redo all my 
code
 to
 use
 Error subclasses and I think we as a community need to get some
consistency.
 It will be annoying to search-replace the names but the alternative
is a
 mess.

 From a previous post Matthew made here is the list of Error 
subclasses
 and
 Exception subclasses in phobos:

 Exception
     Base64Exception
     Base64CharException
     FileException
     ExeModuleException
     ModuleCtorError
     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
         FormatError
         RegExpError
         StreamError
             ReadError
             WriteError
             SeekError
             StreamFileError
                 OpenError
                 CreateError
         ThreadError
         URIerror
         UtfError

 SwitchError (derived from Object)


 This list might be slightly out of date by now but it probably is
still
 fairly accurate. In keeping with what looks like D's convention, I
propose
 - all the non-Error subclasses except ModuleCtorError be made
subclasses of
 Error.
 - the ModuleCtorError class should be renamed ModuleCtorException.
 - objects thrown from user libraries should subclass Error instead 
of
 Exception

 If it would be possible I'd also like to remove or rename 
Exception so
 that

In
 Java
 Throwable is the root of the Error/Exception tree. Maybe D could 
have
 Throwable, Error:Throwable and FatalError:Throwable and we could 
get
 rid
 of
 Exception to avoid confusion with Error.

 -Ben
-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 24 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsc9txdvz5a2sq9 digitalmars.com...
 On Wed, 25 Aug 2004 12:06:22 +1000, Matthew <admin.hat stlsoft.dot.org>
 wrote:
 They should both derive from Throwable, and no user classes should be
 allowed to derive from Throwable.
Given that you can, and may want to catch Errors as well as Exceptions then one should derive from the other, right? otherwise what does the catch block look like?
As usual, remember that I'm a strictophile: Why would anyone want to catch them together? One indicates a recoverable exception, the other an unrecoverable exception? I'm struggling to think of a circumstance where catching them together does not indicate a design error. Anyone, please profer an example to prove me wrong.
 There's no excuse for the current state of the exception hierarchy
 (other than Walter's workload, I supposed). *Please*
 can we have it sorted soon, before people compound the current mess with
 even more blunders.
I agree, it needs to be fixed ASAP.
Let us hope that's not all we'll agree on on this issue. ;)
 Regan

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsc9jbfq75a2sq9 digitalmars.com...
 Something else that seems odd and has been mentioned before is that
 Error
 derives from Exception.

 This seems backwards to me, I know it's a small point, but I think it
 would make more sense if Error were the base class and Exception the
 child
 class.

 Given the idea is that an Exception is recoverable, then Error derived
  from Exception removes this 'recoverable' property, which goes against
 the
 OO concept of child classes always adding to base classes.

 I know the 'recoverable' property is actually a non existant, non
 concrete
 thing and that you could still try to recover after catching an Error,
 but.. it just seems wrong.

 Regan

 On Tue, 24 Aug 2004 15:43:15 -0400, Ben Hinkle <bhinkle mathworks.com>
 wrote:

 whew. Then then std.stream changes will stay (presumably). I think the
 documentation about errors needs updating, too, since it doesn't
mention
 the
 Exception class, only Error.

 "Walter" <newshound digitalmars.com> wrote in message
 news:cgg2cc$1518$2 digitaldaemon.com...
 The idea is that recoverable errors should derive from Exception, and
 non-recoverable from Error. So I think the list here needs revising.

 "Ben Hinkle" <bhinkle mathworks.com> wrote in message
 news:cgfm68$v0g$1 digitaldaemon.com...
 Matthew brought this up before, but can we get some sanity in the
 Error/Exception hierarchy (both in phobos and user code)?

 I looked at some user libraries like mango and deimos and they use
 Exceptions. I have been subclassing Exception without even thinking
about
 it
 because I am so used to Java's scheme. I'm going to redo all my
code
 to
 use
 Error subclasses and I think we as a community need to get some
consistency.
 It will be annoying to search-replace the names but the alternative
is a
 mess.

 From a previous post Matthew made here is the list of Error
subclasses
 and
 Exception subclasses in phobos:

 Exception
     Base64Exception
     Base64CharException
     FileException
     ExeModuleException
     ModuleCtorError
     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
         FormatError
         RegExpError
         StreamError
             ReadError
             WriteError
             SeekError
             StreamFileError
                 OpenError
                 CreateError
         ThreadError
         URIerror
         UtfError

 SwitchError (derived from Object)


 This list might be slightly out of date by now but it probably is
still
 fairly accurate. In keeping with what looks like D's convention, I
propose
 - all the non-Error subclasses except ModuleCtorError be made
subclasses of
 Error.
 - the ModuleCtorError class should be renamed ModuleCtorException.
 - objects thrown from user libraries should subclass Error instead
of
 Exception

 If it would be possible I'd also like to remove or rename
Exception so
 that

In
 Java
 Throwable is the root of the Error/Exception tree. Maybe D could
have
 Throwable, Error:Throwable and FatalError:Throwable and we could
get
 rid
 of
 Exception to avoid confusion with Error.

 -Ben
-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 24 2004
next sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Wed, 25 Aug 2004 15:35:47 +1000, Matthew <admin.hat stlsoft.dot.org> 
wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message 
 news:opsc9txdvz5a2sq9 digitalmars.com...
 On Wed, 25 Aug 2004 12:06:22 +1000, Matthew <admin.hat stlsoft.dot.org>
 wrote:
 They should both derive from Throwable, and no user classes should be
 allowed to derive from Throwable.
Given that you can, and may want to catch Errors as well as Exceptions then one should derive from the other, right? otherwise what does the catch block look like?
As usual, remember that I'm a strictophile: Why would anyone want to catch them together? One indicates a recoverable exception, the other an unrecoverable exception? I'm struggling to think of a circumstance where catching them together does not indicate a design error. Anyone, please profer an example to prove me wrong.
What about.. you have a thread, it calls some code, if any of that throws an error or exception you want to catch it, terminate the thread and pass a error code back to the main thread based on what was thrown. This thread might be a thread that processes records, an error or exception indicates the record is bad, in which case we want to log that, skip it and keep going with the next one.
 There's no excuse for the current state of the exception hierarchy
 (other than Walter's workload, I supposed). *Please*
 can we have it sorted soon, before people compound the current mess 
with
 even more blunders.
I agree, it needs to be fixed ASAP.
Let us hope that's not all we'll agree on on this issue. ;)
Surely not! ;0) Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 24 2004
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
 They should both derive from Throwable, and no user classes should be
 allowed to derive from Throwable.
Given that you can, and may want to catch Errors as well as Exceptions then one should derive from the other, right? otherwise what does the catch block look like?
As usual, remember that I'm a strictophile: Why would anyone want to catch them together? One indicates a recoverable exception, the other an unrecoverable exception? I'm struggling to think of a circumstance where catching them together does not indicate a design error. Anyone, please profer an example to prove me wrong.
What about.. you have a thread, it calls some code, if any of that throws an error or exception you want to catch it, terminate the thread and pass a error code back to the main thread based on what was thrown. This thread might be a thread that processes records, an error or exception indicates the record is bad, in which case we want to log that, skip it and keep going with the next one.
Well, here's where I get to the issue of "correct design". Your example above seems far too ephemeral to draw any real criticisms - deliberate ploy ? :-) - but I'd say you've failed to address the difference between Error and Exception in your example. If there's an exception, then you'd catch that at a certain, suitable, level, which we could reasonably presume would not be at the top-level at which you might catch an Error. Unless, of course, your thread proc is a single function ...
Aug 24 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Wed, 25 Aug 2004 15:43:40 +1000, Matthew 
<admin stlsoft.dot.dot.dot.dot.org> wrote:
 They should both derive from Throwable, and no user classes should 
be
 allowed to derive from Throwable.
Given that you can, and may want to catch Errors as well as
Exceptions
 then one should derive from the other, right? otherwise what does the
 catch block look like?
As usual, remember that I'm a strictophile: Why would anyone want to catch them together? One indicates a recoverable exception, the other an unrecoverable exception? I'm struggling to think of a circumstance where catching
them
 together does not indicate a design error.
 Anyone, please profer an example to prove me wrong.
What about.. you have a thread, it calls some code, if any of that throws an error or exception you want to catch it, terminate the thread and pass a error code back to the main thread based on what was thrown. This thread might be a thread that processes records, an error or exception indicates the record is bad, in which case we want to log that, skip it and keep going with the next one.
Well, here's where I get to the issue of "correct design". Your example above seems far too ephemeral to draw any real criticisms - deliberate ploy ? :-)
Not at all.
 - but I'd say you've failed to address the difference between Error and 
 Exception in
 your example.
Or perhaps in my example I want to treat the two of them the same?
 If there's an exception, then you'd catch that at a certain, suitable, 
 level, which we could reasonably
 presume would not be at the top-level at which you might catch an Error.
Why not? Given that one failure of any kind means the thread cannot complete it's task, why not catch both at the top level and simply report the problem to the main thread?
 Unless, of course, your thread proc is a single
 function ...
Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 24 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsc9xqfgs5a2sq9 digitalmars.com...
 On Wed, 25 Aug 2004 15:43:40 +1000, Matthew
 <admin stlsoft.dot.dot.dot.dot.org> wrote:
 They should both derive from Throwable, and no user classes should
be
 allowed to derive from Throwable.
Given that you can, and may want to catch Errors as well as
Exceptions
 then one should derive from the other, right? otherwise what does the
 catch block look like?
As usual, remember that I'm a strictophile: Why would anyone want to catch them together? One indicates a recoverable exception, the other an unrecoverable exception? I'm struggling to think of a circumstance where catching
them
 together does not indicate a design error.
 Anyone, please profer an example to prove me wrong.
What about.. you have a thread, it calls some code, if any of that throws an error or exception you want to catch it, terminate the thread and pass a error code back to the main thread based on what was thrown. This thread might be a thread that processes records, an error or exception indicates the record is bad, in which case we want to log that, skip it and keep going with the next one.
Well, here's where I get to the issue of "correct design". Your example above seems far too ephemeral to draw any real criticisms - deliberate ploy ? :-)
Not at all.
 - but I'd say you've failed to address the difference between Error and
 Exception in
 your example.
Or perhaps in my example I want to treat the two of them the same?
 If there's an exception, then you'd catch that at a certain, suitable,
 level, which we could reasonably
 presume would not be at the top-level at which you might catch an Error.
Why not? Given that one failure of any kind means the thread cannot complete it's task, why not catch both at the top level and simply report the problem to the main thread?
Mate, if you're kicking off a thread to do a task, and then killing it after doing the one task, then I seriously question your design. If performance matters, you should be thread pooling. If it doesn't, then why are you using a thread? Maybe spawning a worker process would be better suited, and a lot safer to boot! I know you were just throwing out an example, but that's kind of the point. I want to see a real example where Error and Exception *must* be caught together. We can all hypothesise until the cows come home, but it doesn't really count for much.
Aug 24 2004
next sibling parent Sean Kelly <sean f4.ca> writes:
In article <cghc3j$1pcp$1 digitaldaemon.com>, Matthew says...
Mate, if you're kicking off a thread to do a task, and then killing it after
doing the one task, then I seriously
question your design. If performance matters, you should be thread pooling. If
it doesn't, then why are you using a
thread? Maybe spawning a worker process would be better suited, and a lot safer
to boot!

I know you were just throwing out an example, but that's kind of the point. I
want to see a real example where Error and
Exception *must* be caught together. We can all hypothesise until the cows come
home, but it doesn't really count for
much.
Mayube I'm missing something, but why not just catch Throwable? My only concern with Error vs. Exception is that I assume the language should forbid recovery from Errors, and this is a run-time thing. Or is making it a convention good enough? I certainly don't see the problem with having two catch blocks when needed. At worst it's just a small duplication of code. But then what is truly an unrecoverable error? If the stack is corrupted then an exception likely won't make it to a catch block anyway. What else? Sean
Aug 25 2004
prev sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Wed, 25 Aug 2004 16:37:36 +1000, Matthew <admin.hat stlsoft.dot.org> 
wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message 
 news:opsc9xqfgs5a2sq9 digitalmars.com...
 On Wed, 25 Aug 2004 15:43:40 +1000, Matthew
 <admin stlsoft.dot.dot.dot.dot.org> wrote:
 They should both derive from Throwable, and no user classes 
should
 be
 allowed to derive from Throwable.
Given that you can, and may want to catch Errors as well as
Exceptions
 then one should derive from the other, right? otherwise what does 
the
 catch block look like?
As usual, remember that I'm a strictophile: Why would anyone want to catch them together? One indicates a recoverable exception, the other an unrecoverable exception? I'm struggling to think of a circumstance where catching
them
 together does not indicate a design error.
 Anyone, please profer an example to prove me wrong.
What about.. you have a thread, it calls some code, if any of that throws an error or exception you want to catch it, terminate the thread and pass a error code back to the main thread based on what was thrown. This thread might be a thread that processes records, an error or exception indicates the record is bad, in which case we want to log that, skip it and keep going with the next one.
Well, here's where I get to the issue of "correct design". Your
example
 above seems far too ephemeral to draw any real
 criticisms - deliberate ploy ? :-)
Not at all.
 - but I'd say you've failed to address the difference between Error 
and
 Exception in
 your example.
Or perhaps in my example I want to treat the two of them the same?
 If there's an exception, then you'd catch that at a certain, suitable,
 level, which we could reasonably
 presume would not be at the top-level at which you might catch an 
Error. Why not? Given that one failure of any kind means the thread cannot complete it's task, why not catch both at the top level and simply report the problem to the main thread?
Mate, if you're kicking off a thread to do a task, and then killing it after doing the one task, then I seriously question your design. If performance matters, you should be thread pooling. If it doesn't, then why are you using a thread? Maybe spawning a worker process would be better suited, and a lot safer to boot!
Who said I'm not doing any of that? Case 1: I'm using thread pooling, my thread gets an Error or Exception, I return a different code for each, the main process looks at the error code: - if it's an Error it terminates and recreates the thread (or moves on to the next one). - it it's an Exception it re-uses the thread for the next record/task. Case 2: I'm using a worker process.. I don't think this is a good idea in this example, for if my worker process gets an unrecoverable error it would have to terminate, the main process would have to be monitoring it constantly, a thread is much better. I can run a low priority thread where I do not need performance. IIRC a thread and a process are identical on some versions of *nix OS's.
 I know you were just throwing out an example, but that's kind of the 
 point. I want to see a real example where Error and
 Exception *must* be caught together. We can all hypothesise until the 
 cows come home, but it doesn't really count for
 much.
Sure and I agree totally. Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 25 2004
parent reply Sean Kelly <sean f4.ca> writes:
In article <opsdbb95q75a2sq9 digitalmars.com>, Regan Heath says...
Case 1: I'm using thread pooling, my thread gets an Error or Exception, I 
return a different code for each, the main process looks at the error code:
  - if it's an Error it terminates and recreates the thread (or moves on to 
the next one).
  - it it's an Exception it re-uses the thread for the next record/task.
Actually, I think an Error should terminate the application, not the thread. "Unrecoverable" in my mind indicates that something pretty bad happened and that the application as a whole has been left in an undefined state.
Case 2: I'm using a worker process.. I don't think this is a good idea in 
this example, for if my worker process gets an unrecoverable error it 
would have to terminate, the main process would have to be monitoring it 
constantly, a thread is much better. I can run a low priority thread where 
I do not need performance. IIRC a thread and a process are identical on 
some versions of *nix OS's.
Not entirely. Threads share main memory while processes do not. If there are version of *nix where this is not true then I am unaware of them (does any OS allow threads to be launched in a protected memory space? and if so, what's the point of launching a thread and not a process?) Sean
Aug 25 2004
parent Regan Heath <regan netwin.co.nz> writes:
On Thu, 26 Aug 2004 00:38:14 +0000 (UTC), Sean Kelly <sean f4.ca> wrote:
 In article <opsdbb95q75a2sq9 digitalmars.com>, Regan Heath says...
 Case 1: I'm using thread pooling, my thread gets an Error or Exception, 
 I
 return a different code for each, the main process looks at the error 
 code:
  - if it's an Error it terminates and recreates the thread (or moves on 
 to
 the next one).
  - it it's an Exception it re-uses the thread for the next record/task.
Actually, I think an Error should terminate the application, not the thread. "Unrecoverable" in my mind indicates that something pretty bad happened and that the application as a whole has been left in an undefined state.
We (you? Matthew and I) had this argument a few months back and couldn't agree. I still believe that if an important process i.e. mail server etc can report the problem and attempt to soldier on that is a good choice of action. Regardless, I think the course of action should be determined by the programmer, the default could be termination (and indeed it is if you don't catch an Error/Exception) but the choice should remain in the programmers hands.
 Case 2: I'm using a worker process.. I don't think this is a good idea 
 in
 this example, for if my worker process gets an unrecoverable error it
 would have to terminate, the main process would have to be monitoring it
 constantly, a thread is much better. I can run a low priority thread 
 where
 I do not need performance. IIRC a thread and a process are identical on
 some versions of *nix OS's.
Not entirely. Threads share main memory while processes do not. If there are version of *nix where this is not true then I am unaware of them (does any OS allow threads to be launched in a protected memory space? and if so, what's the point of launching a thread and not a process?)
You may well be right, I am by no means an authority on this. Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 25 2004
prev sibling parent reply "antiAlias" <fu bar.com> writes:
There are times that one wants to catch all exceptional circumstances: error
logging for example. However, one can always catch Throwable for such
purposes. Or, indeed, catch Object itself (which I do on occasion; as does
Phobos).


"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cgh8fr$1o00$1 digitaldaemon.com...
 "Regan Heath" <regan netwin.co.nz> wrote in message
news:opsc9txdvz5a2sq9 digitalmars.com...
 On Wed, 25 Aug 2004 12:06:22 +1000, Matthew <admin.hat stlsoft.dot.org>
 wrote:
 They should both derive from Throwable, and no user classes should be
 allowed to derive from Throwable.
Given that you can, and may want to catch Errors as well as Exceptions then one should derive from the other, right? otherwise what does the catch block look like?
As usual, remember that I'm a strictophile: Why would anyone want to catch them together? One indicates a recoverable
exception, the other an unrecoverable
 exception? I'm struggling to think of a circumstance where catching them
together does not indicate a design error.
 Anyone, please profer an example to prove me wrong.

 There's no excuse for the current state of the exception hierarchy
 (other than Walter's workload, I supposed). *Please*
 can we have it sorted soon, before people compound the current mess
with
 even more blunders.
I agree, it needs to be fixed ASAP.
Let us hope that's not all we'll agree on on this issue. ;)
 Regan

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsc9jbfq75a2sq9 digitalmars.com...
 Something else that seems odd and has been mentioned before is that
 Error
 derives from Exception.

 This seems backwards to me, I know it's a small point, but I think it
 would make more sense if Error were the base class and Exception the
 child
 class.

 Given the idea is that an Exception is recoverable, then Error
derived
  from Exception removes this 'recoverable' property, which goes
against
 the
 OO concept of child classes always adding to base classes.

 I know the 'recoverable' property is actually a non existant, non
 concrete
 thing and that you could still try to recover after catching an
Error,
 but.. it just seems wrong.

 Regan

 On Tue, 24 Aug 2004 15:43:15 -0400, Ben Hinkle
<bhinkle mathworks.com>
 wrote:

 whew. Then then std.stream changes will stay (presumably). I think
the
 documentation about errors needs updating, too, since it doesn't
mention
 the
 Exception class, only Error.

 "Walter" <newshound digitalmars.com> wrote in message
 news:cgg2cc$1518$2 digitaldaemon.com...
 The idea is that recoverable errors should derive from Exception,
and
 non-recoverable from Error. So I think the list here needs
revising.
 "Ben Hinkle" <bhinkle mathworks.com> wrote in message
 news:cgfm68$v0g$1 digitaldaemon.com...
 Matthew brought this up before, but can we get some sanity in
the
 Error/Exception hierarchy (both in phobos and user code)?

 I looked at some user libraries like mango and deimos and they
use
 Exceptions. I have been subclassing Exception without even
thinking
 about
 it
 because I am so used to Java's scheme. I'm going to redo all my
code
 to
 use
 Error subclasses and I think we as a community need to get some
consistency.
 It will be annoying to search-replace the names but the
alternative
 is a
 mess.

 From a previous post Matthew made here is the list of Error
subclasses
 and
 Exception subclasses in phobos:

 Exception
     Base64Exception
     Base64CharException
     FileException
     ExeModuleException
     ModuleCtorError
     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
         FormatError
         RegExpError
         StreamError
             ReadError
             WriteError
             SeekError
             StreamFileError
                 OpenError
                 CreateError
         ThreadError
         URIerror
         UtfError

 SwitchError (derived from Object)


 This list might be slightly out of date by now but it probably
is
 still
 fairly accurate. In keeping with what looks like D's convention,
I
 propose
 - all the non-Error subclasses except ModuleCtorError be made
subclasses of
 Error.
 - the ModuleCtorError class should be renamed
ModuleCtorException.
 - objects thrown from user libraries should subclass Error
instead
 of
 Exception

 If it would be possible I'd also like to remove or rename
Exception so
 that

confused.
 In
 Java
 Throwable is the root of the Error/Exception tree. Maybe D could
have
 Throwable, Error:Throwable and FatalError:Throwable and we could
get
 rid
 of
 Exception to avoid confusion with Error.

 -Ben
-- Using M2, Opera's revolutionary e-mail client:
http://www.opera.com/m2/



 --
 Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 24 2004
next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"antiAlias" <fu bar.com> wrote in message
news:cgh8vf$1o7i$1 digitaldaemon.com...
 There are times that one wants to catch all exceptional circumstances: error
 logging for example. However, one can always catch Throwable for such
 purposes. Or, indeed, catch Object itself (which I do on occasion; as does
 Phobos).
For such sledgehammer moments, there's nothing stopping anyone doing the following: catch(Exception x) { // blah-1 } catch(Error x) { // blah-2 } But reinforcing the separation in the general case would, IMNSHO, _add_ to robustness, since it would incline a discipline in design and error-handling responsibility that seems to be sadly lacking in exception-based error-handling languages. And before anyone asks, if blah-1 and blah-2 have to be the same functionality, then either write a function, or use a goto (the one circumstance in which use of goto should _not_ cause equivocation, except amongst the naive). Thor the angry Viking
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cgh8fr$1o00$1 digitaldaemon.com...
 "Regan Heath" <regan netwin.co.nz> wrote in message
news:opsc9txdvz5a2sq9 digitalmars.com...
 On Wed, 25 Aug 2004 12:06:22 +1000, Matthew <admin.hat stlsoft.dot.org>
 wrote:
 They should both derive from Throwable, and no user classes should be
 allowed to derive from Throwable.
Given that you can, and may want to catch Errors as well as Exceptions then one should derive from the other, right? otherwise what does the catch block look like?
As usual, remember that I'm a strictophile: Why would anyone want to catch them together? One indicates a recoverable
exception, the other an unrecoverable
 exception? I'm struggling to think of a circumstance where catching them
together does not indicate a design error.
 Anyone, please profer an example to prove me wrong.

 There's no excuse for the current state of the exception hierarchy
 (other than Walter's workload, I supposed). *Please*
 can we have it sorted soon, before people compound the current mess
with
 even more blunders.
I agree, it needs to be fixed ASAP.
Let us hope that's not all we'll agree on on this issue. ;)
 Regan

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsc9jbfq75a2sq9 digitalmars.com...
 Something else that seems odd and has been mentioned before is that
 Error
 derives from Exception.

 This seems backwards to me, I know it's a small point, but I think it
 would make more sense if Error were the base class and Exception the
 child
 class.

 Given the idea is that an Exception is recoverable, then Error
derived
  from Exception removes this 'recoverable' property, which goes
against
 the
 OO concept of child classes always adding to base classes.

 I know the 'recoverable' property is actually a non existant, non
 concrete
 thing and that you could still try to recover after catching an
Error,
 but.. it just seems wrong.

 Regan

 On Tue, 24 Aug 2004 15:43:15 -0400, Ben Hinkle
<bhinkle mathworks.com>
 wrote:

 whew. Then then std.stream changes will stay (presumably). I think
the
 documentation about errors needs updating, too, since it doesn't
mention
 the
 Exception class, only Error.

 "Walter" <newshound digitalmars.com> wrote in message
 news:cgg2cc$1518$2 digitaldaemon.com...
 The idea is that recoverable errors should derive from Exception,
and
 non-recoverable from Error. So I think the list here needs
revising.
 "Ben Hinkle" <bhinkle mathworks.com> wrote in message
 news:cgfm68$v0g$1 digitaldaemon.com...
 Matthew brought this up before, but can we get some sanity in
the
 Error/Exception hierarchy (both in phobos and user code)?

 I looked at some user libraries like mango and deimos and they
use
 Exceptions. I have been subclassing Exception without even
thinking
 about
 it
 because I am so used to Java's scheme. I'm going to redo all my
code
 to
 use
 Error subclasses and I think we as a community need to get some
consistency.
 It will be annoying to search-replace the names but the
alternative
 is a
 mess.

 From a previous post Matthew made here is the list of Error
subclasses
 and
 Exception subclasses in phobos:

 Exception
     Base64Exception
     Base64CharException
     FileException
     ExeModuleException
     ModuleCtorError
     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
         FormatError
         RegExpError
         StreamError
             ReadError
             WriteError
             SeekError
             StreamFileError
                 OpenError
                 CreateError
         ThreadError
         URIerror
         UtfError

 SwitchError (derived from Object)


 This list might be slightly out of date by now but it probably
is
 still
 fairly accurate. In keeping with what looks like D's convention,
I
 propose
 - all the non-Error subclasses except ModuleCtorError be made
subclasses of
 Error.
 - the ModuleCtorError class should be renamed
ModuleCtorException.
 - objects thrown from user libraries should subclass Error
instead
 of
 Exception

 If it would be possible I'd also like to remove or rename
Exception so
 that

confused.
 In
 Java
 Throwable is the root of the Error/Exception tree. Maybe D could
have
 Throwable, Error:Throwable and FatalError:Throwable and we could
get
 rid
 of
 Exception to avoid confusion with Error.

 -Ben
-- Using M2, Opera's revolutionary e-mail client:
http://www.opera.com/m2/



 --
 Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 24 2004
next sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Wed, 25 Aug 2004 15:47:40 +1000, Matthew 
<admin stlsoft.dot.dot.dot.dot.org> wrote:
 (the one circumstance in which use of goto should _not_ cause 
 equivocation, except amongst the naive).
How can anyone argue with this... it's like asking "have you stopped beating your wife yet?" Regan
Aug 24 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsc9xs2hn5a2sq9 digitalmars.com...
 On Wed, 25 Aug 2004 15:47:40 +1000, Matthew
 <admin stlsoft.dot.dot.dot.dot.org> wrote:
 (the one circumstance in which use of goto should _not_ cause
 equivocation, except amongst the naive).
How can anyone argue with this... it's like asking "have you stopped beating your wife yet?"
Is it? Ok. How so?
Aug 24 2004
parent Regan Heath <regan netwin.co.nz> writes:
On Wed, 25 Aug 2004 16:38:22 +1000, Matthew <admin.hat stlsoft.dot.org> 
wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message 
 news:opsc9xs2hn5a2sq9 digitalmars.com...
 On Wed, 25 Aug 2004 15:47:40 +1000, Matthew
 <admin stlsoft.dot.dot.dot.dot.org> wrote:
 (the one circumstance in which use of goto should _not_ cause
 equivocation, except amongst the naive).
How can anyone argue with this... it's like asking "have you stopped beating your wife yet?"
Is it? Ok. How so?
_if_ I choose to argue with it, I am immediately labeled 'naive'. Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 25 2004
prev sibling parent Sean Kelly <sean f4.ca> writes:
In article <cgh97d$1obd$1 digitaldaemon.com>, Matthew says...
"antiAlias" <fu bar.com> wrote in message
news:cgh8vf$1o7i$1 digitaldaemon.com...
 There are times that one wants to catch all exceptional circumstances: error
 logging for example. However, one can always catch Throwable for such
 purposes. Or, indeed, catch Object itself (which I do on occasion; as does
 Phobos).
For such sledgehammer moments, there's nothing stopping anyone doing the following: catch(Exception x) { // blah-1 } catch(Error x) { // blah-2 } But reinforcing the separation in the general case would, IMNSHO, _add_ to robustness, since it would incline a discipline in design and error-handling responsibility that seems to be sadly lacking in exception-based error-handling languages. And before anyone asks, if blah-1 and blah-2 have to be the same functionality, then either write a function, or use a goto (the one circumstance in which use of goto should _not_ cause equivocation, except amongst the naive).
So use goto to jump out of a catch block? I would probably make that illegal if I wanted to make Errors non-recoverable, at least in the minimal case of Error catch blocks. The easiest way to handle this non-recoverability issue would probably be to have a call to terminate() in a dtor for error and put a hidden delete at the end of Error catch blocks. But I'm not really sure I like this approach. Sean
Aug 25 2004
prev sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"antiAlias" <fu bar.com> wrote in message
news:cgh8vf$1o7i$1 digitaldaemon.com...
 There are times that one wants to catch all exceptional circumstances: error
 logging for example. However, one can always catch Throwable for such
 purposes. Or, indeed, catch Object itself (which I do on occasion; as does
 Phobos).
Did you mean for rethrowing? Why do they need to share? You can still catch Error and Exception separately
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cgh8fr$1o00$1 digitaldaemon.com...
 "Regan Heath" <regan netwin.co.nz> wrote in message
news:opsc9txdvz5a2sq9 digitalmars.com...
 On Wed, 25 Aug 2004 12:06:22 +1000, Matthew <admin.hat stlsoft.dot.org>
 wrote:
 They should both derive from Throwable, and no user classes should be
 allowed to derive from Throwable.
Given that you can, and may want to catch Errors as well as Exceptions then one should derive from the other, right? otherwise what does the catch block look like?
As usual, remember that I'm a strictophile: Why would anyone want to catch them together? One indicates a recoverable
exception, the other an unrecoverable
 exception? I'm struggling to think of a circumstance where catching them
together does not indicate a design error.
 Anyone, please profer an example to prove me wrong.

 There's no excuse for the current state of the exception hierarchy
 (other than Walter's workload, I supposed). *Please*
 can we have it sorted soon, before people compound the current mess
with
 even more blunders.
I agree, it needs to be fixed ASAP.
Let us hope that's not all we'll agree on on this issue. ;)
 Regan

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsc9jbfq75a2sq9 digitalmars.com...
 Something else that seems odd and has been mentioned before is that
 Error
 derives from Exception.

 This seems backwards to me, I know it's a small point, but I think it
 would make more sense if Error were the base class and Exception the
 child
 class.

 Given the idea is that an Exception is recoverable, then Error
derived
  from Exception removes this 'recoverable' property, which goes
against
 the
 OO concept of child classes always adding to base classes.

 I know the 'recoverable' property is actually a non existant, non
 concrete
 thing and that you could still try to recover after catching an
Error,
 but.. it just seems wrong.

 Regan

 On Tue, 24 Aug 2004 15:43:15 -0400, Ben Hinkle
<bhinkle mathworks.com>
 wrote:

 whew. Then then std.stream changes will stay (presumably). I think
the
 documentation about errors needs updating, too, since it doesn't
mention
 the
 Exception class, only Error.

 "Walter" <newshound digitalmars.com> wrote in message
 news:cgg2cc$1518$2 digitaldaemon.com...
 The idea is that recoverable errors should derive from Exception,
and
 non-recoverable from Error. So I think the list here needs
revising.
 "Ben Hinkle" <bhinkle mathworks.com> wrote in message
 news:cgfm68$v0g$1 digitaldaemon.com...
 Matthew brought this up before, but can we get some sanity in
the
 Error/Exception hierarchy (both in phobos and user code)?

 I looked at some user libraries like mango and deimos and they
use
 Exceptions. I have been subclassing Exception without even
thinking
 about
 it
 because I am so used to Java's scheme. I'm going to redo all my
code
 to
 use
 Error subclasses and I think we as a community need to get some
consistency.
 It will be annoying to search-replace the names but the
alternative
 is a
 mess.

 From a previous post Matthew made here is the list of Error
subclasses
 and
 Exception subclasses in phobos:

 Exception
     Base64Exception
     Base64CharException
     FileException
     ExeModuleException
     ModuleCtorError
     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
         FormatError
         RegExpError
         StreamError
             ReadError
             WriteError
             SeekError
             StreamFileError
                 OpenError
                 CreateError
         ThreadError
         URIerror
         UtfError

 SwitchError (derived from Object)


 This list might be slightly out of date by now but it probably
is
 still
 fairly accurate. In keeping with what looks like D's convention,
I
 propose
 - all the non-Error subclasses except ModuleCtorError be made
subclasses of
 Error.
 - the ModuleCtorError class should be renamed
ModuleCtorException.
 - objects thrown from user libraries should subclass Error
instead
 of
 Exception

 If it would be possible I'd also like to remove or rename
Exception so
 that

confused.
 In
 Java
 Throwable is the root of the Error/Exception tree. Maybe D could
have
 Throwable, Error:Throwable and FatalError:Throwable and we could
get
 rid
 of
 Exception to avoid confusion with Error.

 -Ben
-- Using M2, Opera's revolutionary e-mail client:
http://www.opera.com/m2/



 --
 Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 24 2004
prev sibling next sibling parent reply "Bent Rasmussen" <exo bent-rasmussen.info> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message 
news:opsc9jbfq75a2sq9 digitalmars.com...
 Something else that seems odd and has been mentioned before is that Error 
 derives from Exception.

 This seems backwards to me, I know it's a small point, but I think it 
 would make more sense if Error were the base class and Exception the child 
 class.

 Given the idea is that an Exception is recoverable, then Error derived 
 from Exception removes this 'recoverable' property, which goes against the 
 OO concept of child classes always adding to base classes.
That's a matter of interpretation. In the case of Error inherits from Exception the class is specialized for exceptions that are not recoverable. In the case of Exception inherits from Error the class is generalized for exceptions that are recoverable. So in the first case you narrow the use-cases (assuming we have more recoverable exceptions than non-recoverable ones). In the second case you widen the use-cases (assuming the reverse of the first assumption.) I think the usual way to go about it is to ensure that you become more and more specialized as you go down the inheritance chain, not the other way around. For another example, consider the polygon class and the rectangle class. The polygon class is more general than the rectangle class (although also more complex), but a rectangle can be seen as a polygon, but the reverse is not true. Some exceptions are recoverable, some are not. Non-recoverable exceptions should not be the basis for recoverable because recoverable exceptions are not non-recoverable, i.e. they are not errors. It is not the case that you can recover from some non-recoverable exceptions. :-) Either that is true or my logic is screwed. :-)
Aug 25 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Wed, 25 Aug 2004 12:58:56 +0200, Bent Rasmussen 
<exo bent-rasmussen.info> wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsc9jbfq75a2sq9 digitalmars.com...
 Something else that seems odd and has been mentioned before is that 
 Error
 derives from Exception.

 This seems backwards to me, I know it's a small point, but I think it
 would make more sense if Error were the base class and Exception the 
 child
 class.

 Given the idea is that an Exception is recoverable, then Error derived
 from Exception removes this 'recoverable' property, which goes against 
 the
 OO concept of child classes always adding to base classes.
That's a matter of interpretation. In the case of Error inherits from Exception the class is specialized for exceptions that are not recoverable. In the case of Exception inherits from Error the class is generalized for exceptions that are recoverable. So in the first case you narrow the use-cases (assuming we have more recoverable exceptions than non-recoverable ones). In the second case you widen the use-cases (assuming the reverse of the first assumption.) I think the usual way to go about it is to ensure that you become more and more specialized as you go down the inheritance chain, not the other way around. For another example, consider the polygon class and the rectangle class. The polygon class is more general than the rectangle class (although also more complex), but a rectangle can be seen as a polygon, but the reverse is not true. Some exceptions are recoverable, some are not. Non-recoverable exceptions should not be the basis for recoverable because recoverable exceptions are not non-recoverable, i.e. they are not errors. It is not the case that you can recover from some non-recoverable exceptions. :-) Either that is true or my logic is screwed. :-)
You've convinced me :) Someone else suggested a common base called Throwable, this might be the best soln. Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 25 2004
parent "Bent Rasmussen" <exo bent-rasmussen.info> writes:
 You've convinced me :)
 Someone else suggested a common base called Throwable, this might be the 
 best soln.
If error is-an exception is somehow problematic then yes. I screwed up my argument somewhat but maintain that since there are more exceptions than errors, Exception is the proper parent class.
Aug 26 2004
prev sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
I think ideologically it's the right way around. Amost exceptions are 
just that, exceptions, but some of them are errors, which have the 
common ability, or even necessity, to terminate a program when thrown.

However, one shouldn't catch Error ocassionally, so they really should 
be siblings, not parents or children to Exception.

-eye

Regan Heath schrieb:

 Something else that seems odd and has been mentioned before is that 
 Error derives from Exception.
 
 This seems backwards to me, I know it's a small point, but I think it 
 would make more sense if Error were the base class and Exception the 
 child class.
 
 Given the idea is that an Exception is recoverable, then Error derived 
 from Exception removes this 'recoverable' property, which goes against 
 the OO concept of child classes always adding to base classes.
 
 I know the 'recoverable' property is actually a non existant, non 
 concrete thing and that you could still try to recover after catching an 
 Error, but.. it just seems wrong.
 
 Regan
Aug 26 2004
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter wrote:

 The idea is that recoverable errors should derive from Exception, and
 non-recoverable from Error. So I think the list here needs revising.
<snip top of upside-down reply> I see. As long as you've got a clean, application-independent sense of recoverable.... I can see three kinds of errors/exceptions: - development/debugging checks (AssertError, ArrayBoundsError, SwitchError) - internal failures - expectable errors, such as those that tend to result from bad user input, a missing or malformed input file, etc.... Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Aug 26 2004
prev sibling parent reply "Vathix" <vathixSpamFix dprogramming.com> writes:
     AddressException - shouldn't this be derived from SocketException??
     HostException - shouldn't this be derived from SocketException??
I don't think so. Addresses and hosts are separate from sockets. SocketException refers to an exception from a Socket object, not the module.
Aug 25 2004
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Vathix" <vathixSpamFix dprogramming.com> wrote in message
news:cghdv4$1qer$1 digitaldaemon.com...
     AddressException - shouldn't this be derived from SocketException??
     HostException - shouldn't this be derived from SocketException??
I don't think so. Addresses and hosts are separate from sockets. SocketException refers to an exception from a Socket object, not the module.
Agreed. I spotted this blooper - of mine :-( - when this was reposted by Ben. :-)
Aug 25 2004