When an error occurs, I like to have information.  Error messages in
other systems usually don't provide that; for example, a simple
user-dialog which says, "Error" or "Connection Timed Out" but not
telling me whether that was during the connection, the handshake, or
transmitting data.  You're just plain stuck.

The Squeak system can and does better.  The debugger can report all of
the information relevant to the error.  Or, if I don't want to know, I
can just close it.  It is the "ultimate" error message in terms of
friendliness.

Is it the stack-trace itself in the introductory debugger that makes
it unfriendly?  Perhaps if that were removed you would like it better.

 - Chris

On Mon, May 16, 2011 at 5:17 AM, Gary Dunn <garydunnhi at gmail.com> wrote:
> While investigating a bug in Nebrask's telemorphic feature I noticed
> that an attempt to connect to an unavailable computer raised a
> standard looking stack trace type error, like a MNU only it was not a
> message not understood. I think the response should be more user
> friendly so I added a class method named signal: to class
> ConnectionTimedOut
>
> signal: aString
>        "inform user a network socket failed to open"
>
>        ^UserDialogBoxMorph inform: aString  title: 'Connection Timed Out'
>
> This does not solve the larger problem but it does provide a
> friendlier response. I was wondering if this was left out to make
> Squeak more portable, with the understanding that users would develop
> their own code as I did, or is the solution I have a general solution?
> The assumption that an IP address is always available is certainly
> invalid.
>
> Next thing to solve: this connection attempt is not canceled even
> though the timeout was encountered.
>
> --
> Gary Dunn
> Honolulu
>
>