• Ben Hinkle (57/57) Aug 24 2004 Matthew brought this up before, but can we get some sanity in the
• Walter (10/67) Aug 24 2004 The idea is that recoverable errors should derive from Exception, and
• Ben Hinkle (9/87) Aug 24 2004 whew. Then then std.stream changes will stay (presumably). I think the
• Regan Heath (16/113) Aug 24 2004 Something else that seems odd and has been mentioned before is that Erro...
• Matthew (4/120) Aug 24 2004 They should both derive from Throwable, and no user classes should be al...
• Regan Heath (9/155) Aug 24 2004 Given that you can, and may want to catch Errors as well as Exceptions
• Matthew (6/163) Aug 24 2004 As usual, remember that I'm a strictophile:
• Regan Heath (12/36) Aug 24 2004 What about.. you have a thread, it calls some code, if any of that throw...
• Matthew (5/25) Aug 24 2004 Well, here's where I get to the issue of "correct design". Your example ...
• Regan Heath (10/49) Aug 24 2004 Not at all.
• Matthew (7/52) Aug 24 2004 Mate, if you're kicking off a thread to do a task, and then killing it a...
• Sean Kelly (9/15) Aug 25 2004 Mayube I'm missing something, but why not just catch Throwable? My only...
• Regan Heath (18/87) Aug 25 2004 Who said I'm not doing any of that?
• Sean Kelly (9/20) Aug 25 2004 Actually, I think an Error should terminate the application, not the thr...
• Regan Heath (14/45) Aug 25 2004 We (you? Matthew and I) had this argument a few months back and couldn't...
• antiAlias (27/197) Aug 24 2004 There are times that one wants to catch all exceptional circumstances: e...
• Matthew (16/221) Aug 24 2004 For such sledgehammer moments, there's nothing stopping anyone doing the...
• Regan Heath (5/7) Aug 24 2004 How can anyone argue with this... it's like asking "have you stopped
• Matthew (2/8) Aug 24 2004 Is it? Ok. How so?
• Regan Heath (6/16) Aug 25 2004 _if_ I choose to argue with it, I am immediately labeled 'naive'.
• Sean Kelly (8/27) Aug 25 2004 So use goto to jump out of a catch block? I would probably make that il...
• Matthew (2/207) Aug 24 2004
• Bent Rasmussen (21/29) Aug 25 2004 That's a matter of interpretation.
• Regan Heath (8/47) Aug 25 2004 You've convinced me :)
• Bent Rasmussen (3/6) Aug 26 2004 If error is-an exception is somehow problematic then yes. I screwed up m...
• Ilya Minkov (7/23) Aug 26 2004 I think ideologically it's the right way around. Amost exceptions are
• Stewart Gordon (13/15) Aug 26 2004
• Vathix (2/4) Aug 25 2004 I don't think so. Addresses and hosts are separate from sockets.
• Matthew (2/6) Aug 25 2004 Agreed. I spotted this blooper - of mine :-( - when this was reposted by...

"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

"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

"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

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/

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

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/

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

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/

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

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/

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

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

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/

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

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/

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

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

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

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

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/

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

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

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

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/

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

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

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.

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

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