Exceptions don’t have to be handled immediately in time, don’t have to be handled where they are thrown, and don’t have to cause an immediate halt like calling exit(). All of these things are deliberate and useful. Whichever code catches the exception has the option of ignoring it if its unimportant, or repairing the problem and re-trying the operation, if that is possible. That’s why they are called exceptions, not errors. Now, if you have sketchy code that does not have a considered scheme to handle exceptions—throwing without catching—then the default action is usually to halt. That isn’t the fault of exceptions.
When a function or procedure is called in a program, it is typically expected to return something. The value that this function returns is going to be either one of a set of “normal” values, which are the ones you expect to receive if all goes well, or it could be an “abnormal” or “anomalous” value that only returns if “something bad” happens.
That’s common, but bad. It’s better to return status separately from result. Also, it’s ignore-by-default which is not good—you can have too few crashes as well as too many.
The issue that I’m primarily talking about is not so much in the way that errors are handled, it’s more about the way of deciding what constitutes an exception to a general rule, as Google defines the word “exception”:
a person or thing that is excluded from a general statement or does not follow a rule.
In other words, does everything need a rule to be applied to it? Does every rule need there to be some set of objects under which the rule is applied that lie on one side of the rule rather than the other (namely, the smaller side)?
As soon as we step outside of binary rules, we are in Case-when-land where each category of objects is treated with a part of the automation that is expected to continue. There is no longer a “does not follow” sense of the rule. The negation there is the part doing the work that I take issue with.
Exceptions don’t have to be handled immediately in time, don’t have to be handled where they are thrown, and don’t have to cause an immediate halt like calling exit(). All of these things are deliberate and useful. Whichever code catches the exception has the option of ignoring it if its unimportant, or repairing the problem and re-trying the operation, if that is possible. That’s why they are called exceptions, not errors. Now, if you have sketchy code that does not have a considered scheme to handle exceptions—throwing without catching—then the default action is usually to halt. That isn’t the fault of exceptions.
That’s common, but bad. It’s better to return status separately from result. Also, it’s ignore-by-default which is not good—you can have too few crashes as well as too many.
The issue that I’m primarily talking about is not so much in the way that errors are handled, it’s more about the way of deciding what constitutes an exception to a general rule, as Google defines the word “exception”:
In other words, does everything need a rule to be applied to it? Does every rule need there to be some set of objects under which the rule is applied that lie on one side of the rule rather than the other (namely, the smaller side)?
As soon as we step outside of binary rules, we are in Case-when-land where each category of objects is treated with a part of the automation that is expected to continue. There is no longer a “does not follow” sense of the rule. The negation there is the part doing the work that I take issue with.
Exceptions in programming aren’t “exceptions to a rule” , they are “potential problems”.
I really don’t think I can accept this objection. They are clearly considered both of these, most of the time.
I would really prefer that if you really want to find something to have a problem with, first it’s got to be true, then it’s got to be meaningful.