Clearly, it should be a user definable setting. At runtime. If Perl can do it, why can’t anyone else?
Perl has “highly discouraged” this for a very very long time. It was finally deprecated in 5.12 and the old “feature” removed in 5.16.
Haskell’s array allows specifying bounds: https://hackage.haskell.org/package/array-0.5.1.1/docs/Data-Array.html#v:array
So… you open your calendar to work out which meeting room you need to be in in two minutes time and…..
….it pops up an error message to inform you….
…and that it now doesn’t know what the phase of the moon is.
Instead of just telling where you need to be, in ahh, a minutes time, it pops up a complex dialog requesting a new Phase of Moon resource.
If you are http savvy, you understand all this, google for a new phase of moon server and enter it, and sprint to the meeting you’re now late for.
And hopefully your administrator hasn’t been a BOfH and lock the calendar config down and you can update that…
Or if your meeting is about how to decorate the lobby, you probably have no idea what the hell this thing is doing / saying and you start clicking stuff at random, or freeze, or reboot, or…
…or the calendar just quietly deletes that agenda from its list…..
… and later that month you get expelled from your coven for missing the new moon rites.
This feels like a red herring. All those problems still exist if the calendar service keeps hitting the server and getting 410s (or any other error, for that matter). How the calendar reports to the user that a resource is failing is indeed a difficult UX problem. But the point here is, if you are getting a 410 there is no benefit to anyone to keep trying, regardless of how you expose errors to the user.
I know, I’m partly joking.
I’m partly jokingly pointing to a fundamental problem with the UX of something that relies on remote services, not just calendars.
I doubt if there are really nice solutions, and there are doubtless a flock of really horrid solutions that take less time and thought.
An no doubt all the nice solutions do not fall into the definition of a Minimal Viable Product.