Exception handling question

Nevin Pratt nevin at smalltalkpro.com
Tue Aug 5 17:30:02 UTC 2003


This reminds me of an issue that came up with SUnit a few years ago (I 
was using VisualWorks at the time).  There was a version of SUnit where, 
if I put a 'self halt' in the test, SUnit would trap the halt, and not 
actually halt.  An argument was made by many that the SUnit tests should 
run to completion, and *any* errors (#halt or otherwise) should be 
reported, but that the testing framework should otherwise not be 
effected by the error.

I strongly disagreed with that position, and still do.

Plus, I think later versions of SUnit will actually halt when the test 
hits a 'self halt', so it appears that the consesus was also a 
disagreement with the earlier behavior.

Yes, when I say #halt, I really do mean #halt, and I don't want somebody 
else's code trying to second guess what I meant.

Nevin



Stephen Pair wrote:

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

-- 
Nevin Pratt
Bountiful Baby
http://www.bountifulbaby.com
(801) 992-3137





More information about the Squeak-dev mailing list