Three reasons:
1- consistency: the class you put there should trap exceptions of that 
class and all of its subclasses. This rule holds for everything but 
Halt, which then becomes an exception to a nice rule.
2- I want to trap *all* exceptions (I really do), and I *do not* get 
what I asked for. When you trap a Halt using Exception, you get an 
UnhandledError ?!
3-I can already trap Halt anyway if I want, no problem there (and yes, 
then I get a Halt in the handler). It is just that when I do it using 
Exception that I get an UnhandledError in the handler.

On Tuesday, Aug 5, 2003, at 20:52 Europe/Zurich, Lex Spoon wrote:

> "Andreas Raab" <andreas.raab at gmx.de> 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.
>>
>> Or in order to debug some obscure case of event notification failure. 
>> I
>> agree that #halt should halt.
>
> What was wrong with simply making Halt a subclass of Exception instead
> of Error?  People should basically never try to catch Exception, but
> instead Error.  If they really do put Exception there, well, shouldn't
> they get what they ask for?
>
> For example, one reason to catch Exception would be to put in a custom
> debugger.
>
>
> Lex
>
>
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