[ASalazarMX]

> I don't care about a real time or % progress bar...just something that honestly (to OP's point) let's me know that things aren't screwed.

That's where "marquee" progress bars fit in. Those poor abominations that, like Sisyphus, progress without advancing, because a simple activity indicator wasn't user-friendly enough.

[ygra]

Especially fun in Web UIs where the callback that would remove the spinner will never be called because some error occurred somewhere in between and is only logged in the console where no normal user will ever see it ...

Personally I feel that to be very much a subversion of the »things are still moving, so stuff is still happening« assumption that has been common in normal desktop applications.

[GordonS]

Maybe spinners like these need a kind of "dead man's switch", where something needs to keep telling them "yep, still working" every so often, otherwise an error is shown?

[gregmac]

Many APIs don't have that - for example with most IO operations you get a return value when complete or an exception on failure, and that's it.

Getting something like a callback for progress would require modifications all the way down the stack, akin to what's needed for fully async code.

[eyelidlessness]

Then the `try { ... } catch { heartbeat() }` pattern will emerge.

[TeMPOraL]

Which is a sane pattern if a language has proper destructors (a seemingly non-existent thing in GC-enabled languages, unfortunately).

In C++, you'd stack-allocate an object representing a spinner, that spawns said spinner in its constructor, and deletes it in its destructor. Then the spinner doesn't outlive the processing code, no matter what path execution took to end the processing.

There are similar patterns in GC-enabled languages ("with" idiom). Async does throw a wrench into this a bit, though.

[eyelidlessness]

That’s a different pattern than I was trying to illustrate. I was demonstrating unsafely catching/ignoring/hiding errors and asserting health when it’s demonstrably not true

[SulfurHexaFluri]

The app I work on is plagued with this issue. I just wish I was given the time to go around and fix it everywhere.

As with so many of the issues in web apps, its not even complex or hard to fix these issues. Its just no one cares enough to schedule time for it.

[eyelidlessness]

You are a hero. And to the extent you’re unsung, I will sing your praises.

[ASalazarMX]

My ideal spinner would be a decreasing arch, telling the user how much time remains until their request timeouts and fails. Uses the same space as a spinner, but conveys more information.

[eyelidlessness]

> Especially fun in Web UIs where the callback that would remove the spinner will never be called because some error occurred somewhere in between and is only logged in the console where no normal user will ever see it ...

I know it’s unpopular in these parts but checked exceptions would make this impossible.