I like your analysis Jakob!  I agree with everything you said.

What if the Pre-Debug window were re-arranged to look like a
more-conventional error message?   One super easy thing would be to
put the [Proceed]  [Abandon]  [Debug] buttons at the bottom, where
they're normally expected.  And, yes, only the error message would
show in the middle instead of the stack.  This may help with the
intimidation factor you mentioned for users.

I have long held that Squeak should embrace #noviceMode, so we can
customize cases like this to make Squeak what a user wants, or what
developer wants, at the flip of a switch.

Best,
  Chris


>> > One of the things I think we need to collectively get better at (and I suppose it extends to all software developers!) is handling errors more helpfully.
>>
>> What is more helpful than the debugger?
>
> I think a debugger popping up is intimidating for beginners and non-programmer users, and it looks like somebody did not properly guard against error cases.
> Tim and I are neither beginners nor non-programmers, so it is probably even "uncomfortable" for people who just don't know the code that raised the debugger.
>
>>
>>
>> >  It's hard and tedious in too many cases but worth it eventually. Saving a mcz to SqueakSource for example is *really* annoying when it fails after what seems like a lot of faffing just because you forgot to edit the repository stuff to add the uid/pwd. I bet there's a way to test it immediately and get the user to update before carrying on to success, for example.
>>
>> No, the way Monticello handles that now is the right way.
>> [...]  First it saves your Version to
>> your package-cache, [...] you have the saved
>> Version window on your desktop where you can then copy it once you get
>> your connection sorted.
>
>
> New users don't know about this fail-safe mechanism, and probably neither that they can retry the upload with the copy button. Years ago I would have believed that the save failed altogether and I got a worthless, leftover (probably defunct) window for the version anyway. Of course, this perception is wrong, but what tells one otherwise? Some kind of diagnostic and instruction text could do that. One could display it instead of or in addition to a debugger.
>
> We have this notifier window with the proceed, abort, debug buttons. One solution might be to fill it with more helpful text in such situations, instead of the stack trace. Like it is done for Warnings.
>
> "Your version was saved to the disk, but it could not be uploaded to the server. You can retry the upload by using the Copy button on the Version inspector that was opened for you [could add a Text action here to make that SystemWindow flash]. Press "Proceed" to [...]. Press "Abort" to [...]. Press "Debug" to look into the issue. Useful information to mention if you want to ask for help: [exception message or a context-specific excerpt of variables]"
>
> Sometimes I wish for a "Retry" button there and a restart mechanism like the one in Common Lisp.
> http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html
>
>>
>>
>> If we were to improve this area of configuration, let it be to help
>> the user get their mc settings file set up -- because that is the very
>> best solution to that configuration issue.  A one time thing, and they
>> never have fiddle with mc id's / pw's in any image again.
>
>
> Maybe, I didn't know about this settings file until you mentioned it a few weeks ago. Is there anything that tells one how to use it at the moment?
> Note that it does not resolve the situation when there is a connection problem not related to configuration, such as an outage.
>