Reflections on the blues - once again about exception handling
Much has already been written about exception handling in C #, it is written well and in some detail, but I will try to make my modest contribution to this question. This article is simply a kind of attempt to better comprehend and systematize within one, even if a very conventional concept, possible approaches to the problem. The good practice of exception handling, in my opinion, is covered rather poorly and does not create a complete picture when, how and where to deal with exceptions in the code.
It would be nice for developers to keep in mind a kind of “road map” from the very beginning of the project, which would cover all stages of development. “Death is a part of life” - mother told Forest Gampa, emergency situations are part of the system’s normal operation, for this reason, consider the possibility of these most emergency situations, classify them, start working with them already at the design stage, adequately reflect in the code base, and thus organically woven into the structure of the project, it seems to me as important as the implementation of the entire set of full-time functionality.
How to be found, first try to define the terms. Let's take a look at MSDN - “ The C # language's exception handling procedures provide a way to deal with any unexpected situations .” A very interesting place in the formulation is unexpected or exceptional situations . At first glance, it sounds like synonyms, but if one thinks about the difference, it is quite tangible - an exceptional situation during the execution of a specific use case, and some system behavior, the “system use case”, which in itself is an exceptional situation. Let me explain in more detail what I mean. Standard design workflow begins with use case diagrams, which, roughly speaking, project nouns from the specification onto actor-entities, and verbs onto use case-entities. And, with a careful approach to the formalization of the scheme, the entry of the system into each new state (illustrated by the use case), and the exit from it must occur with observance of the fulfillment of preconditions and postconditions. For each state, this set is a unique, common feature - that the execution of this entire set ensures that the system is in the correct, consistent state. Therefore, since the conditions should theoretically be clearly defined already at the design stage, any discrepancy with them gives rise to what can be called exceptional situations in principle.
Further, it is just necessary to mention such a wonderful concept as the “samurai principle”. Its essence is to get the most clearly deterministic, predictable behavior of the code. With the help of ArgumentException, we have the similarity of the filter, which will filter out the incorrect set of input data (also a variation on the subject of preconditions), then by code all questionable places are also subject to exceptions so that the code falls as beautifully and predictably as possible. This technique is more likely to relate to the coding stage, let's say, to the safest implementation of the provided functionality. Here, it will be much more appropriate to mention unexpected situations , since there are no clearly defined preconditions and postconditions, as when working with business requirements, there is simply code that provides certain services and code that consumes these services.
')
Now to the main point - what follows from all this from a practical point of view. Exceptions of the first kind, informing about violation of the set of pre- and post-conditions should be processed as close as possible to the client - the code closest to the client part knows about the expected behavior most of all. This code should be responsible for handling such exceptions. As for exceptions of another kind, unexpected situations, the code that implements this or that functional should work with them - the repository code, if you are working with the database, for example. And in this case, the handler on the contrary should be as close as possible to the place where the exception occurred.
In general, once again, instead of a conclusion, this little note is just reflections on the subject of “negative” scenarios of system behavior, and how to work with them in the best way.
It would be nice for developers to keep in mind a kind of “road map” from the very beginning of the project, which would cover all stages of development. “Death is a part of life” - mother told Forest Gampa, emergency situations are part of the system’s normal operation, for this reason, consider the possibility of these most emergency situations, classify them, start working with them already at the design stage, adequately reflect in the code base, and thus organically woven into the structure of the project, it seems to me as important as the implementation of the entire set of full-time functionality.
How to be found, first try to define the terms. Let's take a look at MSDN - “ The C # language's exception handling procedures provide a way to deal with any unexpected situations .” A very interesting place in the formulation is unexpected or exceptional situations . At first glance, it sounds like synonyms, but if one thinks about the difference, it is quite tangible - an exceptional situation during the execution of a specific use case, and some system behavior, the “system use case”, which in itself is an exceptional situation. Let me explain in more detail what I mean. Standard design workflow begins with use case diagrams, which, roughly speaking, project nouns from the specification onto actor-entities, and verbs onto use case-entities. And, with a careful approach to the formalization of the scheme, the entry of the system into each new state (illustrated by the use case), and the exit from it must occur with observance of the fulfillment of preconditions and postconditions. For each state, this set is a unique, common feature - that the execution of this entire set ensures that the system is in the correct, consistent state. Therefore, since the conditions should theoretically be clearly defined already at the design stage, any discrepancy with them gives rise to what can be called exceptional situations in principle.
Further, it is just necessary to mention such a wonderful concept as the “samurai principle”. Its essence is to get the most clearly deterministic, predictable behavior of the code. With the help of ArgumentException, we have the similarity of the filter, which will filter out the incorrect set of input data (also a variation on the subject of preconditions), then by code all questionable places are also subject to exceptions so that the code falls as beautifully and predictably as possible. This technique is more likely to relate to the coding stage, let's say, to the safest implementation of the provided functionality. Here, it will be much more appropriate to mention unexpected situations , since there are no clearly defined preconditions and postconditions, as when working with business requirements, there is simply code that provides certain services and code that consumes these services.
')
Now to the main point - what follows from all this from a practical point of view. Exceptions of the first kind, informing about violation of the set of pre- and post-conditions should be processed as close as possible to the client - the code closest to the client part knows about the expected behavior most of all. This code should be responsible for handling such exceptions. As for exceptions of another kind, unexpected situations, the code that implements this or that functional should work with them - the repository code, if you are working with the database, for example. And in this case, the handler on the contrary should be as close as possible to the place where the exception occurred.
In general, once again, instead of a conclusion, this little note is just reflections on the subject of “negative” scenarios of system behavior, and how to work with them in the best way.
Source: https://habr.com/ru/post/227195/
All Articles