tim Rowledge wrote:
> 
> On 3-Mar-06, at 3:22 PM, Andreas Raab wrote:
> 
>> Peter Crowther wrote:
>> > Java has had exceptions since the language was devised. In Smalltalk, 
>> > and especially in Squeak, exceptions are
>> > recent additions.  I suspect the reason that Smalltalk error
>> > handling has grown up the way it has, with variants of methods
>> > that don't throw the exception, is because error: didn't give
>> > the option of handling the problem - your code simply failed.
>> > A Squeak exception hierarchy has not been constructed because
>> > we're still moving over from a 30-year-old legacy of throwing
>> > the user into the debugger rather than handling the exception
>> > somewhere in the call stack.
>>
>> I'm not sure I buy that. By your claim it should be the case that 
>> instead of:
> 
> I can't see how what Peter wrote would be interpreted that way.

By first saying "I suspect the reason that Smalltalk error handling has 
grown up the way it has, with variants of methods that don't throw the 
exception, is because error: didn't give the option of handling the 
problem - your code simply failed." which (to me) implies that the 
reason for having variants that take into account potential failure 
(like Dictionary>>at:ifAbsent:) is simply the result of working around a 
limitation and then going on to say "A Squeak exception hierarchy has 
not been constructed because we're still moving over from a 30-year-old 
legacy of throwing the user into the debugger rather than handling the 
exception somewhere in the call stack." which seems to imply that we 
ought to fix this by moving over to an exception handling style.

Cheers,
   - Andreas

>>   map at: key ifAbsent:["something"]
>>
>> one would use something like
>>
>>   [map at: key] on: KeyNotFoundError do:[:ex| ex return: "something"].
> 
> Obviously you *could* do that and if you wanted to explicitly handle a 
> case of the key not being found in your collection it might be the best 
> thing to do.  An 'ifAbsent:' block is great when there is a simple 
> failure case and a simple failure response. I don't think it is so 
> useful when things get more complex and there are many possible problems 
> to handle.
> 
> For an in-memory OrderedCollection, at:ifAbsent: is extremely useful and 
> since pretty much the only thing that can go wrong is the index being 
> outside the collection bounds it covers the problem nicely. For a 
> caching collection hiding a connection to a database I suspect that 
> there are more things that can blow up and more nuanced responses that 
> one would like to provide.
> 
> 
> tim
> -- 
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> "How many Grogs does it take to change a lightbulb?" "One. Something 
> with manipulatory appendages will be along eventually."
> 
> 
> 
>