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
|