Yes, I had my part of the code handy from my custom error handling.

But at the time it seemed to me the tool was for edge cases where one might encounter raw error data with no UI. It never occurred to me to ship an application without error handling, and back then I'd never used LC's so I just assumed it was at least as good as my own.

Since then I've learned that providing any UI for error handling at all is turned OFF by default.

Off.

As in, "Let's make providing a near-useless solution the thing we guide new developers to deliver to their customers."

I was brainstorming with Mark Wieder a few weeks ago about adding static analysis to IDE error reporting, aiming for something closer to the helpful guidance Clang provides. Even if we did little more than show the var values causing something to trip up, it would save tremendous time. Aiming higher seems useful. Other tools are getting better all the time.

And that's for just the IDE. If LC devs are comfortable with state-of-the-art-circa-2003, what we have in the IDE is at least adequate.

For end-users, though, that's where we really want to shine. It's where we NEED to shine.

We want new devs picking up LC to look like heroes, and to deliver that high-quality experience with less effort than they'd put in with other tools.

That's the point. That's why we use LC.

If we can't do that, why are we here?

Everything is undergoing perpetual change. With products there's new customer acquisition on the one side, and attrition on the other. As long as change is happening, why not direct some of it? Why not aim a little higher, to reduce attrition while attracting new users? Sure, we'd all like to see that happen, but a hundred paper cuts unattended undermine that goal.

And as paper cuts go, error handling cuts deep. It only happen when something went wrong. It's an especially sensitive moment in the user journey. We can either lose the user's trust, or retain it. So much about the confidence end-users have in our work hinges on how we handle when things go wrong.

Why not aim higher than the least useful experience?

Or to put this more clearly:

254,11,34
301,2,43
262,67,1
12,22,1
132,1,44
73,68,1
241,67,1
353,0,0
433,2,0
201,0,0
88,3,22
322,4,20
568,22,0

--
 Richard Gaskin
 Fourth World Systems



J. Landman Gay wrote:
On 11/10/20 1:14 AM, Richard Gaskin via use-livecode wrote:
J. Landman Gay wrote:

 > On 11/9/20 3:54 PM, Richard Gaskin via use-livecode wrote:
 >> And WTH happened to LC's error reporting dialog?
 >
 > Standalones have always reported this way on both desktop and mobile.
 > It is up to the developer to include the translated references if
 > they want to see those. Generally I don't bother, I provide the
 > optional built-in ability to send email to support or save a file.
 > I can translate the numbers myself since the meanings usually mean
 > nothing to the end-user anyway.

I've been using my own error-reporting for so long I can't recall seeing the default standalone handling.

I have made a couple of quickies where I just used LC's error reporting, but clumsy as that design is at least the output from the "Send Report" button is more useful than the raw list of triplet integers. >
How has such ungraceful error handling become acceptable?

Why is the least useful thing the easiest for new developers to do?

Shouldn't it be easy for LC devs to deliver a great application experience?


I can't remember a time when it *didn't* report the triplets outside of the IDE. That's why you and I wrote the Error Lookup stack. ;)

--
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com


_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Reply via email to