I agree with what you have in this answer by Eduardo Binotto. It is a mechanism that signals an exceptional event. Achoachava that everyone agrees with this. But there are some people that I think should be in straitjacket who do not think so :D
Here comes the details and the disagreements begin to appear. In his answer There is an example that for me is not an exception (and it seems that he conceptually agrees with me, maybe not at the time of doing). It is an abuse of the mechanism because it does not "occur when something outside the common rule happens". Invalid data is a common rule. It is part of the domain to have 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 (you can see in my profile and networks what is my experience, and yes I’m crawling on it, don’t you?). Modeling is very difficult and exceptions or other mechanisms are part of the model, establishes contracts.
And the thing gets 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) one chooses 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 the TryParse()
one of the best examples when an invalid data communication should not be made with exception.
And I didn’t even mention the fact that exceptions are slow.
When you throw excess exceptions your consumer code is bound to do what it shouldn’t. The worst exception is spurious (which is just noise read more in this reply).
So it is often best to treat invalid data, abnormal condition or even in some cases failure with something not exceptional.
The mechanism itself functions as a super drop. In any language. The release of the exception (throw
or other word) is a drop somewhere I don’t define previously. The catch
is the label that drop with the aggravating fact that only at the moment of the execution is known where it is in the general flow. It is in another routine. This can create flow problems, have to take specific care because the method can be terminated without action of its own code.
Usually people criticize much less dangerous resources, which have much less risk potential. They often 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 defend the exception. What’s more, it’s often used in ways that don’t make the code shorter.
There’s a myth that says the code has to treat the exception, which we see in practice is not true, not even with verified exceptions. What it requires is that you have 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 whoever likes the mechanism starts 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 usually 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 thing is to try to treat this in the code, it should only alert to the problem for the programmer to fix the error.
In general exceptions should be used when it does not matter much the specific treatment. Some languages created their culture to be used to pass messages to consumer code, which conceptually should be something not exceptional.
Basic is a system output to inform the programmer/user that there is no way to proceed with the processing queue of that request
– Rodrigo Gomes