How to properly handle errors in C#?

Question

C++ / C#

We need literature or articles on how to work with errors and logs in the .NET environment, in particular C #, from an architectural point of view. Those. when and how to throw an Exception, and when not to, etc.
Those. need some philosophy :) or best practices, thanks in advance.

Answer 1

Those. need some philosophy

And what books have you already tried to read, since you ask this?
After all, the philosophy is very simple. The idea of ​​error handling using the exception mechanism is to not clutter up the main algorithm with error handling logic and to be able to localize this processing in one place, and not just anywhere, but exactly where it is known how to handle the error.
The use of the exception mechanism together with the OOP hierarchical classification makes it possible to generalize exceptions of various natures, if the code for their handling is also general and does not go into the details of the error.
All this gives you a set of simple rules:
1) you need to throw an exception when you are not going to handle the situation that has arisen within the framework of the current algorithm. In other words, for the currently running function, this situation is "exceptional". Example: You are writing a function to read a GIF file into a Bitmap, and as you read it, check that the resulting data matches the GIF file format (for example, make sure there is a GIF89a at the beginning of the file). If suddenly you see that the file format is violated, then you have no choice but to throw an exception, because. you cannot continue the execution of the main algorithm - reading the file. Inside the read function, you don't know ahead of time how the calling code will want to handle the problem, and you don't need to know;
2) you need to catch an exception of a specific type when the task of the current code includes error handling too. In other words, when the exception in the called code is only one of the options for the normal operation of the calling code. Let's return to the example with GIFs: if for the library function of reading a file, format violation is a critical problem, then for the GUI application calling this function this is a normal situation - it can and should be processed by issuing the appropriate message to the user, or simply skip the file if it is processed immediately a few pictures. Or, for example, if you're writing a web service, you probably don't want the entire service to crash because of an error while processing a single request. Therefore, in a web server that distributes files, for example, you can intercept all FileNotFoundexceptions, and throw a 404 error, and for all other exceptions inside the request handler - a 500 error, and in both cases write to error.log.
It should be understood that exceptions are just one approach to error handling that naturally fits in with the capabilities of some languages. In C, for example, they do without them, and everyone is alive and well.
A great example of different approaches is the Parse / TryParse methodsfor numeric types in dotnet. The first returns a value and throws an exception, the second writes the value through the output parameter, returns a bool and does NOT throw an exception. The "Try" in the name of the second method emphasizes that for this method, failure to parse a number from a string is a NORMAL situation, and the method will return false in this case. For the Parse method, on the contrary, this situation will be exceptional, because it will simply have nothing to return, and further normal operation of the code, including the calling one, is impossible.
Therefore, the TryParse method is more often used when the probability of an error is high and its processing is one of the branches of the algorithm. For example, when reading user input, we can immediately ask the user to correct the entered value.
On the other hand, Parse is used when an error is unlikely, we are not ready to handle it, and it is better to abort the entire operation. For example, if we receive an invalid response from the server, we will not ask it to correct this response. It is better to interrupt further communication with the server, because there is a violation of the protocol and you can break firewood.

Answer 2

On this topic, quite a few copies have been broken, up to the complete rejection of the try / catch / finally construct as an implicit goto. In my own code, I keep the possibility of throwing an exception to a minimum, and each case is discussed with the lead or the architect - whether it is needed there or not.

Answer 3

There is also such a thing as Contract. Many people prefer to use it instead of try/catch.