> On 2021-12-30, at 2:07 PM, mail at jaromir.net wrote:
> 
> so cool the debugger after FileList cancel is gone :) This should never be a part of "normal" user interaction... 

Damn right; it might be excusable in a developer scenario but as a general occurrence it is appalling.

I've been digging around to examine what is going on with that. Basically I suspect it got left that way because too few people bothered to handle any situation where a file request goes wrong; it is sometihng that can be a bit complicated. My best suggestion is that the 'cancel' option of the default handler should return nil and all the senders need to be updated. I have 'fixed' a few so far and it seems to make sense. I'd note that a few senders have some interesting approaches to handling the exception; ZipArchiveMember>>#extractInDirectory:overwrite: for example uses 
`	file := [fileDir newFileNamed: localName] on: FileExistsException do:[:ex| ex return: nil].
	file ifNil:[ `
And Morph>>#saveOnFile: uses
`	file := [[FileStream newFileNamed: fileName]
				on: FileExistsException
				do: [:err | err defaultAction]]
				on: Error
				do: [:err | ^ self].`
... both of which are interesting but maybe a bit cumbersome for widespread usage. In a lot of places I'd suggest using FileStream class>>#newFileNamed:do: since that already handles a nil file - but it doesn't currently handle the exception issue in any special way. If the default action were to return a nil, that would be much better.

Problem right now is that it is a lot more changes than we should be contemplating for this release.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Oxymorons: Silent scream