Henning Thielemann wrote:
It is not possible to handle errors in a way like exceptions, because exceptions are (rare but) expected situations, that can well be handled. In contrast to that you do not know the concrete errors in your program, otherwise you would have fixed them already.
I agree with you that it makes sense to reflect this conceptual distinction in our module system, and in our hierarchy of exceptions and errors. However, this distinction is only really useful during development. Once a system is deployed, there is little difference. In the face of an error, it is often just not an option to print a rude error message and shut down the system. Picture, for example, a program that is controlling an aircraft in flight, or that is participating in sensitive negotiations for a valuable business deal. Instead, the system must do the best it can to keep a smile on its face and keep going. Any condition that could interfere with normal operation is the same, it doesn't matter whether the reason is a programming error or anything else. So we also need a way to treat all exceptional conditions the same in a deployed system, whether or not they are "errors". Historically, a famous example is the cryptic error condition that kept popping up every few seconds as the Apollo 11 lander was about to touch down on the moon. All eyes in Mission Control were on the person who wrote the program. Sweat pouring down his back, he just kept saying quietly, "Go."