I was looking at approving this changeset after Roel reviewed it, but I 
have one question... it would appear based on this simple test that 
Exception *does* currently handle a halt (without filing in Anthony's 
changeset):

[3 + 4. self halt] on: Exception do: [Transcript show: 'pickles'; cr]
"shows 'pickles'"

[3 + 4. self halt] on: Error do: [Transcript show: 'pickles'; cr]
"halts, does not show 'pickles'"

[3 + 4. self halt] on: Halt do: [Transcript show: 'pickles'; cr]
"shows 'pickles'"

After filing in this changeset, the behavior for these tests is the 
same.

Possibly my tests are missing something, though?

But anyway, moving Halt to be a subclass of Exception (not Error) seems 
like the right thing to do.

- Doug


On Tuesday, August 5, 2003, at 11:56 AM, Anthony Hannan wrote:

>> From preamble:
> Halt was being treated as a special case in Exception class >> 
> #handles:
> to avoid being handled by error handlers.  This changeset removes Halt
> as a subclass of Error making it an indendent exception class (direct
> subclass of Exception), and removes the special case test from
> #handles:.
>
> Roel Wuyts <wuyts at iam.unibe.ch> wrote:
>> Aha. So who would be willing to change it? I don't feel comfortable 
>> with
>> doing it myself, unless there are enough unit tests around...
>>
>> On Monday, Aug 4, 2003, at 19:00 Europe/Zurich, Anthony Hannan wrote:
>>>>> The most important point however is that Exception DOES NOT
>>>>> handle Halt (in spite of the fact that Halt is a subclass of
>>>>> Exception.)
>>>> Can somebody motivate this decision (or whether it is an 
>>>> unintentional
>>>> bug)?
>>>
>>> I'm not the author but I believe the reason is so "self halt" will
>>> always halt and not be accidentally handled by a earlier Error 
>>> handler.
>>> The better solution is probably to not make Halt a subclass of Error
>>> but just a direct subclass of Exception.
>
> <HaltNotAnError-ajh.cs>