In article <cgh97d$1obd$1@digitaldaemon.com>, Matthew says...
>
>
>"antiAlias" <fu@bar.com> wrote in message news:cgh8vf$1o7i$1@digitaldaemon.com...
>> There are times that one wants to catch all exceptional circumstances: error logging for example. However, one can always catch Throwable for such purposes. Or, indeed, catch Object itself (which I do on occasion; as does Phobos).
>
>For such sledgehammer moments, there's nothing stopping anyone doing the following:
>
>    catch(Exception x)
>    {
>        // blah-1
>    }
>    catch(Error x)
>    {
>        // blah-2
>    }
>
>But reinforcing the separation in the general case would, IMNSHO, _add_ to robustness, since it would incline a discipline in design and error-handling responsibility that seems to be sadly lacking in exception-based error-handling languages.
>
>And before anyone asks, if blah-1 and blah-2 have to be the same functionality, then either write a function, or use a goto (the one circumstance in which use of goto should _not_ cause equivocation, except amongst the naive).

So use goto to jump out of a catch block?  I would probably make that illegal if I wanted to make Errors non-recoverable, at least in the minimal case of Error catch blocks.  The easiest way to handle this non-recoverability issue would probably be to have a call to terminate() in a dtor for error and put a hidden delete at the end of Error catch blocks.  But I'm not really sure I like this approach.


Sean

On Wed, 25 Aug 2004 16:38:22 +1000, Matthew <admin.hat@stlsoft.dot.org> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsc9xs2hn5a2sq9@digitalmars.com...
>> On Wed, 25 Aug 2004 15:47:40 +1000, Matthew
>> <admin@stlsoft.dot.dot.dot.dot.org> wrote:
>> > (the one circumstance in which use of goto should _not_ cause
>> > equivocation, except amongst the naive).
>>
>> How can anyone argue with this... it's like asking "have you stopped
>> beating your wife yet?"
>
> Is it? Ok. How so?

_if_ I choose to argue with it, I am immediately labeled 'naive'.

Regan

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

On Wed, 25 Aug 2004 16:37:36 +1000, Matthew <admin.hat@stlsoft.dot.org> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsc9xqfgs5a2sq9@digitalmars.com...
>> On Wed, 25 Aug 2004 15:43:40 +1000, Matthew
>> <admin@stlsoft.dot.dot.dot.dot.org> wrote:
>> >> >> > They should both derive from Throwable, and no user classes 
>> should
>> >> be
>> >> >> > allowed to derive from Throwable.
>> >> >>
>> >> >> Given that you can, and may want to catch Errors as well as
>> >> Exceptions
>> >> >> then one should derive from the other, right? otherwise what does 
>> the
>> >> >> catch block look like?
>> >> >
>> >> > As usual, remember that I'm a strictophile:
>> >> >
>> >> > Why would anyone want to catch them together? One indicates a
>> >> > recoverable exception, the other an unrecoverable
>> >> > exception? I'm struggling to think of a circumstance where catching
>> >> them
>> >> > together does not indicate a design error.
>> >> > Anyone, please profer an example to prove me wrong.
>> >>
>> >> What about.. you have a thread, it calls some code, if any of that
>> >> throws
>> >> an error or exception you want to catch it, terminate the thread and
>> >> pass
>> >> a error code back to the main thread based on what was thrown.
>> >>
>> >> This thread might be a thread that processes records, an error or
>> >> exception indicates the record is bad, in which case we want to log
>> >> that,
>> >> skip it and keep going with the next one.
>> >
>> > Well, here's where I get to the issue of "correct design". Your 
>> example
>> > above seems far too ephemeral to draw any real
>> > criticisms - deliberate ploy ? :-)
>>
>> Not at all.
>>
>> > - but I'd say you've failed to address the difference between Error 
>> and
>> > Exception in
>> > your example.
>>
>> Or perhaps in my example I want to treat the two of them the same?
>>
>> > If there's an exception, then you'd catch that at a certain, suitable,
>> > level, which we could reasonably
>> > presume would not be at the top-level at which you might catch an 
>> Error.
>>
>> Why not? Given that one failure of any kind means the thread cannot
>> complete it's task, why not catch both at the top level and simply report
>> the problem to the main thread?
>
> Mate, if you're kicking off a thread to do a task, and then killing it after doing the one task, then I seriously
> question your design. If performance matters, you should be thread pooling. If it doesn't, then why are you using a
> thread? Maybe spawning a worker process would be better suited, and a lot safer to boot!

Who said I'm not doing any of that?

Case 1: I'm using thread pooling, my thread gets an Error or Exception, I return a different code for each, the main process looks at the error code:
 - if it's an Error it terminates and recreates the thread (or moves on to the next one).
 - it it's an Exception it re-uses the thread for the next record/task.

Case 2: I'm using a worker process.. I don't think this is a good idea in this example, for if my worker process gets an unrecoverable error it would have to terminate, the main process would have to be monitoring it constantly, a thread is much better. I can run a low priority thread where I do not need performance. IIRC a thread and a process are identical on some versions of *nix OS's.

> I know you were just throwing out an example, but that's kind of the point. I want to see a real example where Error and
> Exception *must* be caught together. We can all hypothesise until the cows come home, but it doesn't really count for
> much.

Sure and I agree totally.

Regan

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

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

You've convinced me :)
Someone else suggested a common base called Throwable, this might be the best soln.

Regan.

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

In article <opsdbb95q75a2sq9@digitalmars.com>, Regan Heath says...
>
>
>Case 1: I'm using thread pooling, my thread gets an Error or Exception, I return a different code for each, the main process looks at the error code:
>  - if it's an Error it terminates and recreates the thread (or moves on to
>the next one).
>  - it it's an Exception it re-uses the thread for the next record/task.

Actually, I think an Error should terminate the application, not the thread. "Unrecoverable" in my mind indicates that something pretty bad happened and that the application as a whole has been left in an undefined state.

>Case 2: I'm using a worker process.. I don't think this is a good idea in this example, for if my worker process gets an unrecoverable error it would have to terminate, the main process would have to be monitoring it constantly, a thread is much better. I can run a low priority thread where I do not need performance. IIRC a thread and a process are identical on some versions of *nix OS's.

Not entirely.  Threads share main memory while processes do not.  If there are version of *nix where this is not true then I am unaware of them (does any OS allow threads to be launched in a protected memory space?  and if so, what's the point of launching a thread and not a process?)


Sean

On Thu, 26 Aug 2004 00:38:14 +0000 (UTC), Sean Kelly <sean@f4.ca> wrote:
> In article <opsdbb95q75a2sq9@digitalmars.com>, Regan Heath says...
>>
>>
>> Case 1: I'm using thread pooling, my thread gets an Error or Exception, I
>> return a different code for each, the main process looks at the error code:
>>  - if it's an Error it terminates and recreates the thread (or moves on to
>> the next one).
>>  - it it's an Exception it re-uses the thread for the next record/task.
>
> Actually, I think an Error should terminate the application, not the thread.
> "Unrecoverable" in my mind indicates that something pretty bad happened and that
> the application as a whole has been left in an undefined state.

We (you? Matthew and I) had this argument a few months back and couldn't agree.

I still believe that if an important process i.e. mail server etc can report the problem and attempt to soldier on that is a good choice of action.

Regardless, I think the course of action should be determined by the programmer, the default could be termination (and indeed it is if you don't catch an Error/Exception) but the choice should remain in the programmers hands.

>> Case 2: I'm using a worker process.. I don't think this is a good idea in
>> this example, for if my worker process gets an unrecoverable error it
>> would have to terminate, the main process would have to be monitoring it
>> constantly, a thread is much better. I can run a low priority thread where
>> I do not need performance. IIRC a thread and a process are identical on
>> some versions of *nix OS's.
>
> Not entirely.  Threads share main memory while processes do not.  If there are
> version of *nix where this is not true then I am unaware of them (does any OS
> allow threads to be launched in a protected memory space?  and if so, what's the
> point of launching a thread and not a process?)

You may well be right, I am by no means an authority on this.

Regan

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

Walter wrote:

> The idea is that recoverable errors should derive from Exception, and
> non-recoverable from Error. So I think the list here needs revising.
<snip top of upside-down reply>

I see.  As long as you've got a clean, application-independent sense of recoverable....

I can see three kinds of errors/exceptions:

- development/debugging checks (AssertError, ArrayBoundsError, SwitchError)

- internal failures

- expectable errors, such as those that tend to result from bad user input, a missing or malformed input file, etc....

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

> You've convinced me :)
> Someone else suggested a common base called Throwable, this might be the
> best soln.

If error is-an exception is somehow problematic then yes. I screwed up my argument somewhat but maintain that since there are more exceptions than errors, Exception is the proper parent class.

I think ideologically it's the right way around. Amost exceptions are just that, exceptions, but some of them are errors, which have the common ability, or even necessity, to terminate a program when thrown.

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

-eye

Regan Heath schrieb:

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