What to aim for: less errors, or "good" errors?

The thought popped into my head yesterday while waiting at the bus stop. Every technological device we use malfunctions at some time or other, we only notice when it's an especially "bad" error. For example, I got a new phone recently, the LG Optimus Slider which is basically the next version of my previous phone, the Optimus V. Both the Slider and the V have an issue with the 3G where it will stay "Connecting" but never connect, especially when switching off Wifi. I learned that toggling airplane mode tends to get it working about 90% of the time, and the other 10% requires a restart of the phone.

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:

1. This dumb error message in Zoundry Raven 
2. Microsoft giving no indication whatsoever why an installation failed (or useless vague error codes)

The 1st case is exceeding obvious. For the 2nd, the first installer did not give any indication at all as to why the installation failed. The second installer gave a crypted error code that apparently means a dozen different things, which does nothing for you except have you trying out a dozen different fixes. I only fixed the problem by checking the log for the second installer (the first installer did not give you the location of a log) which linked to another log that I had to scan through until I found the error message. Bad error.


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.
-Bry