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

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

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

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

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

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

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

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

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