"self error:" and the out of box experience
Ned Konz <ned <at> bike-nomad.com>
2001-02-13 16:58:27 GMT
Some time ago exceptions were added to the various file opening routines.
Unfortunately, the way this was done is not too user-friendly.
I found this out by decompressing a .gz file in the FileList that had already
I got a little popup menu that explained that the file already existed, and
giving me the choices of:
* overwriting the file
* renaming the file (presumably the new one)
I canceled the operation and was faced by a debugger because the cancel
self error: 'Please close this to abort file opening'
Now, this didn't bother me too much, because I'm used to seeing walkbacks,
but I wonder about using debuggers as a primary user interface mechanism.
Note that there are 89 senders of newFileNamed: in the image, and many of
them are called by "user-level" tools. Any of them could bring up a debugger.
And "self error:" is used for handling of other routine errors. For instance,
Celeste>>sendMail: will raise a debugger when there's any kind of socket
error on its SMTP server connection.
I then tried to wrap Error handling around the perform:orSendTo: and found
that I wasn't being notified about the potential file overwrite.
Why not? Because FileExistsException is a subclass of Error, and my Error
handler caught and ignored it.
It seems like there's several problems here.
* As a user, I'd expect that canceling an operation would do just that. I've
already made a choice, so why should I also have to close a debugger window?
* As a programmer, I'd like to be notified that the user canceled an
operation. But I have no idea that the Error exception I got was because a
user canceled (why should this be an Error, anyway?).
* As a programmer, I'd like to handle _real_ Errors separately from
notifications like "old file doesn't exist" or "new file already exists". But
having these notifications be subclasses of Error makes it hard to provide
error handling, as I have to anticipate all possible notifications that are
also subclasses of Error, and trap them separately. This causes tighter
coupling to existing code, not less.
* Provide a separate UserCanceledNotification (a subclass of Notification)
to signal these choices
* Add appropriate handling for this notification around invocations of
user-level operations (perhaps up in MenuItemMorph>>invokeWithEvent: and also
in the button morph code)
* Remove error notifications wherever cancels happen.
* Move FileDoesNotExistException and FileExistsException under Notification
currently: Stanwood, WA
email: ned <at> bike-nomad.com