When exceptions are needed

Foreword

The topic of Exceptions (pros and cons) is not new, and has already been discussed more than once. But still, I hope that everyone who read this article will learn something new and useful for themselves.

The reason for the publication of this publication was the reluctance to keep silent and just watch the Internet being filled with “all-knowing” programmers who teach beginners in our field to hammer nails with a microscope, finding dozens of arguments in defense of their methods! Therefore, this publication is directed, rather, at the novice comprehending programming and asking questions. She is my "correct answer."

So, what is Exception?

The exception is that the probability (possibility) of which is excluded by the system ... this is something that cannot happen in the conditions of the program.
')
Look in your code. Can you add to each exclusion “but this is impossible” or “but this is excluded”? I think few people can honestly answer "yes." If your answer is “no”, then part of the exceptions are not really those, you just used this mechanism, because you thought it was more convenient. That very “convenience” of such an approach will be considered further.

Who should determine which situations the program excludes and which not?

All exceptions can be dictated only by task or common sense , and nothing or anyone else. The exception is not determined by the type of data or their source, although it is often possible to hear or read in the smart articles: “Wrong customer input can not be an exception” ... do not believe it! Here, simply, do not believe in this.

You can get quite a reasonable exception to the client input in the task: “Specially trained managers of our company will work with the system, because the input of incorrect data is excluded” or “The manager will upload letters to the system that have already passed the format validation, therefore the format will always be exactly such". Now the customer himself told you where to throw an exception in the program written for him (and it's okay that this is client input). Of course, if we are still talking about a certain product, and not a library, the program should not be simply dropped. Let an exception handler hang at the top level and turn all unhandled exceptions into errors, save the data and delicately complete the execution (or transfer control to the main module if the error is not in it).

But, as usual, do not forget to read between the lines and clarify the task. If you are asked to save the file, specify if it is possible that the file will not be saved. And if you decide not to specify, then do not exclude such a probability, but implement the reaction to this event. Your code should not be silent about anything.

Or provide, or exclude.

Why is any extra Exception harmful to the code?

Not once faced with a situation where a negative result of the function was returned as an exception, although this result was provided for by the task itself. On this account I heard various explanations:

• Do not pass the completion flag for the entire call chain.
• I need to transfer data collected before receiving a negative response
• The function can return a negative result for three reasons. It's easier to convey this reason.
• many other reasons ...

Why not do this? Yes, because:

• You can not safely use the already written methods in other places, because they can raise unexpected exceptions;
  
  
• GOTO is evil - because it confuses code by transferring control to an arbitrary point. You should not think that transferring control, jumping an arbitrary number of calls on the stack, confuses your code less than GOTO;
  
  
• Someone, and perhaps you yourself, then you will need to fix something or add in the written code. We should not assume that after 2 years you will recall that this system module uses negative exceptions for negative answers. That is, you have to delve into ... and delve into not only the code, but also all the "unusual" approach.

I didn’t include such arguments as “the rule of good tone” and “let's use everything for its intended purpose” in the list above, so it’s already written enough.

Conclusion

I tried not to go into unnecessary details and put maximum sense in every sentence. I hope I did it, and reading these lines, you think: “five minutes, and so much new!” Well, I hope so.

Finally, I would like to say that we should not dodge under the pressure of factors, timing and “just as easy,” and write the wrong code, but quickly.

The perfection and fault tolerance of our code determines our professionalism.