User interaction vs. headlessness vs. exception handling

Ned Konz ned at bike-nomad.com
Mon Jul 24 06:25:40 UTC 2000


Tim Rowledge wrote:

> Exception handling is generally pretty tricky. Typically there is little
> actual use of it in the image for people to use as examples and so there
> ends up being little pressure to extend its use.

My experience with Smalltalk has been 5 years of doing machine control
in VisualWorks. Exception handling around everything. Threads interrupting
other threads with various notifications. And all of this working with
their debugger (well, actually, the Crafted Smalltalk debugger by Terry
Raymond as soon as I discovered it).

I can't imagine doing real-world work (that is, anything connected
to the world outside the Smalltalk process) without exception handling.

Aren't most Smalltalkers used to using exception handling? If not, how
do they handle timeouts from network connections, etc.?

> And so it gets
> forgotten by most people. I can't actually agree that the exception
> handling in Squeak is particularly fine; I get bitten too often by it
> truncating stacks in a debugger.

Does it work worse than, say, the VW 2.5 debugger? I _do_ miss having
Process>>interruptWith:, and I've heard of problems (I guess since fixed)
with intermediate stack frames with nil senders or something.

> Better tools are needed to help with
> debugging when exceptions are used since they always seem to cut the
> visible connections between layers of code. Separating the dependencies
> is good, but tools need to help us keep them alive in our understanding.

What would you suggest? Is this a simple fix to the debugger, or is it
something that's missing in ST80 in general? After all, the action on
an exception is to unwind the stack up to the handler. Is this the
problem you have with the current tools? Or is there something more missing?
(guess I have to look at it more closely).

I wrote a Process Browser (and posted it to the list), but it can't do
much, since it's missing interruptWith: . Another tool along this line
is a Semaphore Browser (actually, I'd like a tool that shows Processes
_and_ Semaphores together).

> If you have time to start cleaning up this, please do! Lots of us would
> welcome it.

Well, I'd like to see EH work properly.

What would you attack first?

-- 
Ned Konz
currently: Stanwood, WA
email:     ned at bike-nomad.com
homepage:  http://bike-nomad.com





More information about the Squeak-dev mailing list