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 
been decompressed. 

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)
	* canceling

I canceled the operation and was faced by a debugger because the cancel 
choice did
	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.

I'd suggest:

	* 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
-- 
Ned Konz
currently: Stanwood, WA
email:     ned at bike-nomad.com
homepage:  http://bike-nomad.com