The point is, yeah, it's an error that I deal with pretty frequently, but I never even registered it in my mind as a problem because 90% of the time, it has a fix that is quick and easy. However, 10% of the time, it has a fix, but that fix takes a long time (relatively) and it keeps me from using my phone during that entire time. It's pretty obvious that the prior is better than the latter. Obviously, most tech users would say "Well the best case would be to have no errors at all," but both as a user and a future developer, I know well enough that there will always be errors. But how you handle the errors as they happen is a totally different matter.
The true question is, which should developers focus on: keeping the number of errors to a minimum, or making sure that errors are "good" when they happen? One can't focus entirely on one or the other. Let's use some kind of game as an example: if you focus on lessening the errors, the game will be playable but as soon as an error is happened upon, the game will just exit and the player will lose saved data; if you focus on handling errors well when they happen, the game will be buggy as hell. Both are undesirable, so the solution must be in the middle, but which end does it favor?
Here are 2 examples of exceedingly "bad" errors:
- This dumb error message in Zoundry Raven
- Microsoft giving no indication whatsoever why an installation failed (or useless vague error codes)
Personally, I would tend to lean on the handling of errors rather than prevention. Almost every piece of tech I have has "quirks", and quirks are just errors handled better. (Except for the sticky keys on my calculator...that was Dr. Pepper.) Occasionally Firefox crashes or freezes, but if it starts up again with my tabs and tab groups, I can get back to what I was doing right away. Quirks become small bumps that you can just glide over whereas full blown errors make you slam on the breaks.
My thoughts, anyway. I'm sure they are to change as I get to developing more software and deal with errors.