Way of indicating an error

tim Rowledge tim at rowledge.org
Mon Feb 26 16:38:23 UTC 2007


On 26-Feb-07, at 8:23 AM, Damien Cassou wrote:


>
> Would you think that a new Stream hierarchy should be more coherent
> and clearer, or do you think it should keep compatibility ?

If you are freshly implementing or completely re-implementing some  
capability you should do it in the way you believe to be correct.

I suggest that a part of working out what is correct is to see how  
you would use it and how you would explain it. If what you thought  
was correct turns out to be impossible to explain or cumbersome to  
use in code then there is a *really* good chance you weren't right  
about the design!

I can think of several ways of signalling an error
a) return a special value  - say nil - that has to be checked by user  
code
b) set some variable that has to be checked by the user  code
c) signal an exception that has to be handled by user code
d) use the pattern of passing in a block to be evaluated on an error  
#at:ifAbsent: etc
e) exit the program as vigourously as possible - like VAXen used to  
do for divide by 0. :-)


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: DST: Deadlock System Tables





More information about the Squeak-dev mailing list