Why is there “Unknown error” in real life? [duplicate]

Question

This question already has answers here:

How much information about an error should be shown to the user? (6 answers)

Closed 5 years ago.

As a programmer, I always try my best to explain what happened in the code when I have to show an error message, for example:

try {
    int a = b / 0;
} catch (NumberFormatException ex) {
    System.out.println("There was a problem with the number: " + ex.getMessage());
}

I think this is a very basic practice that everyone should follow. But in real life, we still see some "unknown" errors with no error code nor anything we could follow to find the reason, like this one, or this one.

I mean, every "error" has a reason, so why there is "Unknown error"? Can anyone explain this for me?

Answer 1

Because whoever was in charge of the information system didn't consider it worthwhile to preserve this information.

That is the basic reason in all such cases. However, many different motives can be behind that assumption (and in fact, they can be both reasonable and unreasonable).

• Someone didn't think that anything could go wrong at all. It is rare for developers to be aware of all the things that can go wrong, and some don't have any awareness of the potential for exceptional conditions except the ones they have themselves encountered.

• They didn't think that preserving the information was worth the additional effort. Using try on every action that might throw exceptions is a horrible strain on readability, and the information that is preserved may often be completely unintellegible to the average user anyway.

• Increasingly, people work on isolated parts of large systems and don't have the information they would need to do this. With internet-deployed systems, very often the details of an error that caused a failure of service never leave the server on which it occurred. Any code running on a different machine is then fundamentally unable to explain the problem.

• The full details are not the thing you would want to know. A division by zero is intuitively understandable, but the vast majority of exception stack traces are ultimately caused by variations of 'resourceManager is null'. It's technically true, but it doesn't help you at all with understanding or resolving the problem. Is the resourceManager supposed to be nullable (i.e. is my code faulty, or theirs)? How do I get a valid resourceManager? Did this happen because I accessed something to early? How can I avoid that? Do I even need a resource manager, or is that module a part of the system that I shouldn't be using in the first place? All these and thousands of other questions are not answered by an exception stack trace no matter how meticulously you report it, so maybe preserving the specifics of the error condition athand is not as useful as other mitigation measures would be.

Answer 2

Computer programs as they grow on a large scale, become very complex. They act according to very precise logic (machine instructions), and there are many environmental factors which can affect this logic and change its direction.

Then sometimes we just [can] catch an error has occurred and to understand the reason needs a deep analysis of the software and even operating system and maybe a lot of time.

You may have noticed that many scenarios are possible for an small program, such scenarios grow exponentially when the software get larger and links to Operating System or I/O devices.