All programmer life (about 1 year) I am tormented by the question: why do we need exception handling? Is it difficult to just use a condition? A frequent example for using exceptions in textbooks (in my case in C ++) is division by zero. When the user enters 2 numbers and, if the second (divisor) is zero, an exception is thrown. But why do you need to do this? Why can't I immediately display the text of the error and end the program (or pass it to the calling module)?
From my own experience I can offer the following view on the choice of options using exceptions:
Wherever it is not necessary, it is NOT worth using exceptions.
The most compelling reasons are:
- Exceptions are not intended for organizing normal ways to run a program. As an example, this complicates the task (or makes it generally impossible at all) to predict the path of program execution (result: branch miss predication). Accompanying such a code also becomes a non-trivial task.
- Decreases speed. Support for the exclusion mechanism is not free, because compilers have to create add. checks and exception interceptors, support the objects of the exceptions themselves, etc. This may especially unexpectedly “shoot” on some exotic platform at the wrong time.
- Requests the user in advance to use the exception mechanism for working with your code.
- Inter-modular (i.e., beyond a binary module, for example, a DLL) passing exceptions is a bad practice. The fact is that instead of intercepting by reference, a user can use the interception of an exception object by value, which will result in a copy of the original exception object being created at the client in a completely different environment. In addition to inefficiency, it is also unsafe.
- Lack of understanding of how this mechanism works. Trite, but very vital.
"Well, when should they be used?"
Exceptions should be used in the following cases:
- It is known in advance that neither in this place of the code nor in the immediate client it is impossible to correctly handle a serious error. Then it remains to send an exception "somewhere higher", in the hope that "there" they know what to do.
- If necessary, notify the client of the inability to correctly create (initialize) an object — by throwing an exception in the constructor. On the other hand, you can initialize an object using, for example, the
Init()function, which returns an error code, and allow the client to decide for himself whether to use exceptions.
Both approaches are permissible, but the variant with exceptions can be more elegant and compact.
Can. And what's more, there are two large programmer camps - some consider that exceptions should be made, others that only the return code should be checked. In reality, it is sometimes impossible to check all the conditions and it is easier to put exception handling - for example, if a third-party library code is called.
It also happens that if you do all the checks, the code turns into a set of checks.
Exceptions are one of the most attractive means of language. You just need to learn how to use them correctly. Contrary to popular belief, the use of exceptions is much broader than the banal error handling. It is especially convenient to use them to transfer control (and, possibly, data) at once through several levels in the call hierarchy. Or not even calls, but simply nested blocks of code. The name itself as it hints at us that exceptions are intended to work with exceptional situations that are not at all obliged to be erroneous. They only have to be exceptional compared to the normal course of the program. So exceptional that it does not make sense to do a preemptive check each time.
Exceptions are very good. In principle, you can do without them and use standard return codes, but there are also inconveniences in using return codes. 1. With the use of exceptions, practically there will be no problems with temporary objects. Threw exceptions - all unfinished objects crashed down. And do not worry what memory to clean and so on. 2. If you need to send information about problems in the cascade call of functions from the lower level to the upper check return codes become painful and very cumbersome.
I switched to a new job, there a large amount of code was written using exceptions. When trying to reuse the code, of course they began to climb out where not needed, and generate errors. I had to rewrite the old code under the usual checks.
In general, exceptions remind me of the goto construction, only worse, because transfer control to the levels above. With a large number of exceptions, especially if the same ones are generated in different places, debugging the code is VERY difficult.