The ANSI standard exposes the situations in the programming interface. It requires a separate class for each situation, which I think is overkill.
This is not entirely true. The only thing that ANSI actually requires is that there are a couple of globals (e.g., MessageNotUnderstood, ZeroDivide) that respond to the right kind of messages. Whether these are instances of a single class or actual classes is irrelevant.
Andreas
-- PLEASE NOTE NEW EMAIL ADRESS!
+===== Andreas Raab ========= (andreasr@wdi.disney.com) ==+ | Walt Disney Imagineering Phone: +1 818 544 5016 I I Glendale, CA Fax: +1 818 544 4544 I +======< http://isgwww.cs.uni-magdeburg.de/~raab >========+
The only thing that ANSI actually requires is that there are a couple of globals (e.g., MessageNotUnderstood, ZeroDivide) that respond to the right kind of messages. Whether these are instances of a single class or actual classes is irrelevant.
Perhaps I was reading too much into it. I have draft 1.1, which says in section 8.5.7: "Exception is an abstract class. There are very few if any other abstract classes required by the standard. This class is needed so that new types of exceptions can be created within its subclass hierarchy."
That was how Digitalk did it, which I assume was the inspiration for the ANSI exception-handling framework.
-C
-- Craig Latta composer and computer scientist craig.latta@netjam.org www.netjam.org latta@interval.com Smalltalkers do: [:it | All with: Class, (And love: it)]
On the plus side of having a class for each exception situation, the information relevant to the situation does not have to be passed around as a single amorphous "parameter". The Exception subclass can have as many instance variables to properly describe the situation as needed. Better yet, it can also include the error analysis and recovery methods specific to the situation. Quite in the "everything is an object" style.
--Vassili
On the plus side of having a class for each exception situation, the information relevant to the situation does not have to be passed around as a single amorphous "parameter". The Exception subclass can have as many instance variables to properly describe the situation as needed. Better yet, it can also include the error analysis and recovery methods specific to the situation.
I agree that would be nice if I needed it, but I never have. I've always found that the receiver in the handler's scope is the best delegate for such behavior. There's usually so much information residing with it that coordinating with a "smart" exception would just be annoying.
But I assume there are Digitalk developers who have experienced otherwise...
-C
-- Craig Latta composer and computer scientist craig.latta@netjam.org www.netjam.org latta@interval.com Smalltalkers do: [:it | All with: Class, (And love: it)]
Raab, Andreas wrote:
-- PLEASE NOTE NEW EMAIL ADRESS!
+===== Andreas Raab ========= (andreasr@wdi.disney.com) ==+ | Walt Disney Imagineering Phone: +1 818 544 5016 I I Glendale, CA Fax: +1 818 544 4544 I +======< http://isgwww.cs.uni-magdeburg.de/~raab >========+
Congratulations, Andreas, on your new job!
--Alan
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Alan Lovejoy Content-Disposition: attachment; filename="vcard.vcf"
Attachment converted: Anon:vcard.vcf 10 (TEXT/ttxt) (000074DC)
squeak-dev@lists.squeakfoundation.org