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

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

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

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/

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/

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/

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

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/

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

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