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.

>
>   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."