Use Exception (updated version).

throw new Exception or not throw new Exception, that is the question!

Good time of day!

When to use the technology of exceptions? When is it better to abstain and is it worth refraining?

')
Some time ago, I tried to describe the practice of using the Exception approach when it’s worth and when it’s not worthwhile to use this technology. It turned out I, to put it mildly, not very. But I got a portion of “healthy” criticism :). For which many thanks: smira habralan tagirovarthur Thecentury . So, who does not mind, can share with them the pluses;).

Getting down to business

I once asked questions: “When should I use Exception technology?” (The emphasis is on C #). Sometimes I have such situations that you wonder whether it is worth using or not worth ... Digging into the Internet, I learned that there are 2 camps (as it should be) - supporters and opponents of using Exception. Camp opponents, led by Joel Spolsky .
Here I will give a list of the arguments that Joel uses:
1. They are "not visible" in the source code. I will explain in more detail. Suppose you call a certain method of a certain class:
someClass.SomeMethod ();
You cannot say with certainty whether an exception will be thrown. You do not need to throw slippers at me; in Visual Studio, when you hover the mouse over a method, you can see a hint of what exception can be thrown (provided that the developers made this description in the documentation). I do not know how in other IDEs, but in VS there is such an opportunity. Of course, this is an undoubted minus for those who profess the "true faith", tobish Notepad (or analogues) and the compiler.

2. Create "unexpected" exit points from the method. Suppose you have a code like this:
someClass.PossibleException ();
otherClass.DoOtherThing ();
so, there is no guarantee that the DoOtherThing () method will be executed if the PossibleException () method throws an exception.

3. Exception `s slower mechanism than the" return code error. " Joel for some reason did not mention anything about it, so this argument was added by me. Why is this a slower version we analyze below.

Apparently 3 arguments (2 from Joel and 1 from me :)). While quite reasonable. The speed of a spherical horse in a vacuum is nothing to do with

And now let's consider the arguments in favor of this approach:
1. This is the PLO approach, invented and created within the framework of this concept. I think it’s not necessary to paint the benefits of the PLO approach over the “classical” one, everyone is well aware.

2. Ease of use. Consider the classic example, you have a class method SomeMethod (), which returns an integer - the error return code, you inherit from the class containing this method and overload it, in order to extend the functionality. Thus, the method could return, suppose, the values ​​{1,2,3,4}; after expansion {1,2,3,4,5, ..., 10}. This will cause an increase in the code, which should handle the result of the work method. So for example, you use ArgumentException; You can add the generation of this exception by changing its content. Those. thus, you can reduce the confusion created by the large number of return codes.

3. High degree of infomability. An error occurred in the called method, you can get an error code and then dig into the documentation or source code, looking for the causes of this error. Or you can get the contents of the stack (find out where exactly the error occurred), get some kind of clear text message (provided that the developers did not write throw new Exception ("");), and there are a lot of other useful things that are strongly able to make life easier for the developer (for more detailed information, you should refer to the documentation).

4. Principle of use. In principle, this echoes the first item, but I chose to take it out separately. Suppose some method in the depth of the stack generated an exception. And the method that calls it does not know what to do, then the exception is passed to a higher level. In the end, either a handler will be found that will adequately respond to this exception, or ... a “message to the user”. I try to apply the first approach in my practice. In the case of the error return code, it is extremely convenient to drive the error “upward” in search, “and who should process it?”, And sometimes it is not possible, because one method can return an int, another bool, in the end, we never know what happened.

As you can see 3: 4. Moreover, from the point of view of the developer, the use of exceptions is more convenient.

Now I would like to tell you why exceptions are a slower mechanism: an exception object is created, and a handler is searched for in the call stack that could handle this exception. What by itself "consumes" time. There is nothing free in life, something needs to be spent (money / time / nerves / etc).

As can be seen from the above comparison, exceptions are more convenient. But do not abuse them. Exceptions precisely for this reason are named so that they should arise only in exceptional situations! If you read 2 bytes from a file, there is no fundamental difference - they should be in this order or in reverse. Do not drive the code that creates the exception faster. You can simply swap them and continue to work further. An example is a bit contrived, but I think it is understandable :).

Now, I think it is worth summing up:
Exceptions should be used, but with the mind! For myself, I singled out one situation where I will not use them - if I receive data that is initially bad and only the speed of the program’s work is critical for me, because the data cannot be “straightened” for one reason or another, then I will not use exceptions. In all other cases, I would prefer to use exceptions. I think in my fabrications I am not alone.