> 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 at netjam.org
www.netjam.org
latta at interval.com
Smalltalkers do: [:it | All with: Class, (And love: it)]