And, I'd argue that when I say #halt, I mean #halt, and don't want your 
handler to trap it.  I could equally make the case in your example that 
halting the process without you trapping it is exactly what I want to 
happen in order to debug your exception handlers.  We should probably 
have a mechanism for both (sort of like a graceful process termination 
vs. killing a process...in this case, a graceful halt vs. a forced halt).

- Stephen

Roel Wuyts wrote:

> I definitely want it to raise an exception :-)
>
> Suppose: the system change notification is integrated in the kernel, 
> and your changeset is a dependent (just like some browsers, etc, but 
> these are less 'criticial'). Then I come along, implementing some new 
> tool that needs to get notifications. So I make myself a client, but 
> because I am just starting out to program this thing, I put a 'self 
> halt' to see what events I get, and implement my stuff.
>
> This is a realistic scenario, but depending on the order the clients 
> of the events are notified in, it might be that the change which 
> triggered the event (captured by my new application raising a halt)  
> never makes it into the changes file. To properly capture these things 
> I'd like to catch this halt and take some action (queue up other 
> events, etc.). If halt directly opens a debugger I cannot react on this.
>
> But, and hence my first mail, this means that I want all exceptions to 
> be the same. I am not going to test whether a UnhandledError was 
> raised (and then see whether the source was a halt), when all the 
> other events are processed in another way (only Halt is an exception 
> on the rule; no pun intended).
>
> On Monday, Aug 4, 2003, at 19:13 Europe/Zurich, Stephen Pair wrote:
>
>> Anthony Hannan wrote:
>>
>>> Roel Wuyts <wuyts at iam.unibe.ch> 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.
>>>
>>
>> Or, don't signal an exception at all...why not make #halt do what is 
>> says and just #halt the process and open a debugger...I've never 
>> understood why you'd want #halt to raise an exception.  You never 
>> want to handle it and you always want to it stop the current process 
>> and open a debugger...so, what's the point in signaling an exception?
>>
>> - Stephen
>>
>>
>>
>>
> Roel Wuyts                                                   Software 
> Composition Group
> roel.wuyts at iam.unibe.ch                       University of Bern, 
> Switzerland
> http://www.iam.unibe.ch/~wuyts/
> Board Member of the European Smalltalk User Group: www.esug.org
>
>


-- 
- Stephen
_________
Do you need:
  Web/Domain/Application Hosting?
  Mailing List Services?
  IMAP/POP3/Web Email Accounts?
  Instant Messaging Accounts hosted on your domain?

Email me for information.