I agree with everything you have in this response from Eduardo Binotto. It is a mechanism that signals an exceptional event. I think everyone agrees.
Here comes the details and the disagreements start to appear. In the another response from him has an example that for me is no exception (and it seems that he agrees conceptually with me, maybe not at the time of doing). It is an abuse of the mechanism because it does not "occur when something out of the ordinary happens." Invalid data is common rule. It is part of the domain to have an invalid data. It is not an exceptional situation.
Defining what is exceptional or not is a complicated task and depends on a lot of experience. I'm still crawling on it. Modeling is very difficult and exceptions or other mechanisms are part of the model.
And things get worse because there are cases where the model says that something is not exceptional, but by optimization (not performance, but to facilitate the writing of a code) we choose to use an exception even if the situation is not exceptional. This is often necessary because it does not have a better mechanism.
The general rule is not to control the program flow with exceptions, but there may be cases where this is advantageous.
I consider TryParse()
one of the best examples when invalid data communication should not be done with exception.
And I did not even mention the fact that exceptions are slow .
When you throw in excess exceptions, your consumer code is required to do what you should not. The worst exception is spurious (which is just noise read more on this answer ).
So often it is better to treat the invalid data, the abnormal condition or even in some cases the failure with something something not exceptional .
The mechanism itself functions as a super goto . In any language. The exception throw ( throw
or another word) is a goto for some place I do not previously define. The catch
is the label of that goto with the aggravating factor that only at the moment of execution will know where it is in the general flow. He's in another rut. This can create flow problems, you have to take special care because the method can be terminated without action of your own code.
People often criticize far less dangerous resources, which have much less risk potential. Often they adopt the mechanism to make the code smaller in certain situations. What I find strange is that other more implicit things are criticized by the same people who espouse the exception. What's more, it is often common for it to be used in a way that does not leave the code shorter.
There is a myth that says that the code forces the exception to handle, which we see in practice that is not true, even with exceptions checked. What compels you is to have a completely invalid information for the compiler itself, and then you have to treat to use the valid value to compile, and this is done with error code (see the last link ).
So what do you like the mechanism to start using without thinking about the model, without establishing whether it is part of the rule or not.
It aggravates the situation because the exception is often used for different purposes in most languages, even more so in dynamic languages. The exception is used to generate programming errors. Of course, it is an exceptional situation, although it should have a different mechanism, this is a clearly exceptional case and its use is fair. The wrong way is to try to handle this in the code, you should only alert the problem to the programmer fixing the error.
In general, exceptions should be used when the specific treatment does not matter much. Some languages have created their culture to be used to pass messages to the consumer code, which should conceptually be non-exceptional.