Andreas,

>Exception handling done in the right way is not at all trivial. I have
>reviewed some of the proposed mechanisms and found quite some pitfalls in
>the code I've seen. Changing some serious system code to something that
>might eventually crash your system is nothing I'd be willing to do for a
>public release. And, since I don't have the time to fix or clean up the
>existing stuff the only thing I can do (and have done) is sending messages
>to those folks working on it.


[snip]

>I'm not sure if I understand the above. Do you mean we were then *forced*
to
>clean up this stuff? I wouldn't like this idea very much - if the stuff is
>not on my priority list it would distract me from the work I want/have to
>do. Unfortunately you are right (even if you didn't intend to say so ;-) -
>it would in fact force us to clean up all the stuff that's been submitted
if
>we ever wanted to get out of an experimental state. Maybe that is part of
>the problem we're discussing here: There is a lot of stuff going on on the
>outside but it is not always in a state that makes inclusion in the system
>useful or is even ready for it (I have seen quite a bunch of changes that
>had very bad side effects). And while trying out new ideas and sending
>around change sets for people to play with surely is a good idea, the
notion
>of 'start something and leave the dirty part to Squeak Central' is not
>exactly my understanding of working together.
>

Think Bazaar, not Cathedral. I agree that the public release of Squeak
should not have dangerous or unproven code in it. On the other hand, a
cutting edge version should have experimental code in it. If you would just
release Squeak with ANY exception framework then you might be surprised at
how well this works. Suddenly a whole new set of eyes see and use the code.
If its' utter garbage and crashes the image, then it wont last a day. People
will just remove the code. If it has problems, then everyone can see them
and attack them in parallel. If other code shows more potential, people will
put that up instead. The more people that look at and use the code, the
quicker the bugs will show up. The point is, you need to have something
there for people to focus on and improve, even if it is embryonic. This will
also help the development of teamwork instead of everyone doing it all on
their own (for example two versions of OS events, +/- three versions of
exceptions, x versions of Linux sound support). This is not the same as
leaving the dirty work for Squeak Central - it is just a way of making more
effective use of the large user/developer base.

Peter