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
|