Thread overview | |||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
August 24, 2004 standardize Error and Exception subclassing | ||||
---|---|---|---|---|
| ||||
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 people used to Java or C#'s naming convention don't get 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 |
August 24, 2004 Re: standardize Error and Exception subclassing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ben Hinkle | 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 > people used to Java or C#'s naming convention don't get 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 > > |
August 24, 2004 Re: standardize Error and Exception subclassing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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 > > people used to Java or C#'s naming convention don't get 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 > > > > > > |
August 25, 2004 Re: standardize Error and Exception subclassing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ben Hinkle | 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 >> > people used to Java or C#'s naming convention don't get 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/ |
August 25, 2004 Re: standardize Error and Exception subclassing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | 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 > >> > people used to Java or C#'s naming convention don't get 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/ |
August 25, 2004 Re: standardize Error and Exception subclassing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | 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 >> >> > people used to Java or C#'s naming convention don't get 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/ |
August 25, 2004 Re: standardize Error and Exception subclassing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | "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 > >> >> > people used to Java or C#'s naming convention don't get 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/ |
August 25, 2004 Re: standardize Error and Exception subclassing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | 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/ |
August 25, 2004 Re: standardize Error and Exception subclassing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | 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 > > >> >> > people used to Java or C#'s naming convention don't get 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/ > > |
August 25, 2004 Re: standardize Error and Exception subclassing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | > >> > 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 ...
|
Copyright © 1999-2021 by the D Language Foundation