Error Messages Are Evil

[Dar Scott]

Sure.  Here is a belabored example of my style of tenacious I/O.

I typically start one each of a communications “machine" with <prefix>Start command and stop it with <prefix>Stop.  The status is available though a status function and notification of the status change by a callback.  

A very simple example is a TCP service.  

Almost always present is the part of the status that says the machine is on or off.  That is, the start handler has been called.

A fundamental part of the status for such a service is whether a listening port is set up correctly.  That part of the status might have values “listening” or “can’t listen (<latest reason>)”.  The callback allows this to be displayed as a green light or a red light, or it might never get to the user.  

If the machine gets an error on accept (usually because you left a test standalone running or forgot to shut down some OS service) that status will remain “can’t listen”.  The machine keeps trying every half second or so, depending on the need.  It doesn’t block in the start.  I use 'send … in … seconds’.

Quit that offending application and this one has a green light indicator immediately.

This same thing applies to a gadget that looks like a serial adaptor.  “Oh.  It’s not plugged in.”  Plug it in and everything starts working.  Want to move it to the front?  Unplug it, the light goes red, plug it back in and the light turns green.  All is working.  

Now, think of something more complicated, such a machine that allows you to pass an array from one app to the other.  In that case write errors might mean trying again, even trying to take things down and building them again.  The machine keeps trying everything, kicking and biting, to do what you want.  Heartbeat messages back and forth let your code and perhaps the user know what the current state of affairs is:  communicating. 

You can see the current state in the status.  

So, a status for array sender might be “on, receiver open, sender open, receiving, sending, high error rates”.  

So, in my communications modules, I say, “Don’t tell me you can’t, just let me know how well you are doing.  Just keep at it.  Wen’t down a bunny trail?  Then backtrack or start over if you have to.”  

This is also important when there are lots of components to a complex system and I expect the system to work no matter the order the components got started or got past hurdles.

If you have an application blocking a network port you wanted to use, you want to shut it down and everything start working.  You don’t want to say, “OK, I think I found the problem, everybody shut your systems down and then bring them come up when I say.  We should be able to grab an early breakfast within the hour or so.”  

The important goal is if everything is in the right state and in the right environment, it works.  It doesn’t matter how it got there.  

I call this tenacious I/O.  Some have called it Dar’s badger programming.  

This does not apply to isolated request-response situations, such as making a REST query with LiveCode URL.  But it might apply to a simple REST server.  It might apply to some higher level function that needs to work doggedly at getting something done that includes making REST queries.   

Most of what I do with this is for control, but it also applies to physical security and distributed systems.

I also design protocols are are highly resistant to errors.  

Dar


On May 11, 2014, at 5:21 PM, J. Landman Gay <jacque at hyperactivesw.com> wrote:

> I'm interested.  Can I get an example? I know Apple discourages error dialogs now.  
> 
> On May 11, 2014 5:44:47 PM CDT, Dar Scott <dsc at swcp.com> wrote:
>> Often I design communications without error responses to commands. 
>> Instead there is state information while the underlying system is
>> working doggedly to make what you wanted work.  
> 
> -- 
> Jacqueline Landman Gay         |     jacque at hyperactivesw.com
> HyperActive Software           |     http://www.hyperactivesw.com
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode