Exception handling question
Roel Wuyts
wuyts at iam.unibe.ch
Wed Aug 6 07:38:21 UTC 2003
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
More information about the Squeak-dev
mailing list
|