C exception handling approach#
The question is more focused on an architectural approach or refactoring. For example, there is a console application where there is a FileWorker class that works with files, an instance of which is initialized in Programm. cs at the entry point (main) and further work with its methods is performed. Is it correct for exception handling to place the try catch block only at the main entry point, as they say, to throw errors up when exceptions are thrown, or do you still need to hang try catch directly inside methods and classes? I want to avoid overexposing the syntax of quotation marks, etc. - to come to conciseness. And I would also like to know how to elegantly handle exceptions of asynchronous methods (asynh await), how to throw them to the main thread?
2 answers
Not always and not all exceptions should be thrown "up". For example, you work with communication channels-you download a file through the network, or parse a site or something else you do and you have an error-the connection was cut off/the timeout came out/the antivirus blocked the file for verification. Is it good in this case to throw an exception to the very top in main? Of course not! There are errors, after which you should catch the exception approximately in the place where it was thrown (or slightly higher in the code-depending on how you have it refactoring is done) and make something from the following (or maybe several items at once):
- Pause and try to perform the last operation again (and so several times in the loop)
- Put the processed item back in the processing queue (do you have a processing queue?), increasing the number of attempts made for this item and marking when the last attempt was made
- Send a letter to the pre-registered addresses with the text " Chief, everything is gone, the cast is removed, the client is leaving! "
- Clean up the disk space, restart the service, overload the modem...
These actions should be done at the appropriate level of the program. And you can think of many such examples. Therefore, you need to look at where you have a whole task that should be executed in one block and catch exceptions so that you can easily repeat this block of actions as needed.
But at the same time, they usually catch exceptions at the very bottom, where there was a problem, at least to log it where you can collect as much information about it as possible - what kind of error occurred, with what parameters the function was called at that moment, etc. (what file and where we tried to send or receive, for example), and then throw the exception above.
There are many subtleties and it is difficult to give universal advice. But in any case, you need to take into account many factors and look at the design of the program, at its execution flows, and not just catch exceptions there, where someone told you to do it.
And you need to clearly understand the design of your program - which methods can throw exceptions, and which ones can't, so that you know when and where it is better to catch these exceptions, and where it is not necessary to do this, so as not to slow down the execution of the program and not to clutter the code.
This is all good, but how to make the code more readable, if you do not throw Exceptions at the top. I want the error handler to be one on the client calling side (main) at the entry point, where objects are initialized and work with them is going on, I do not want to pile up try catch blocks under their hood, in order to avoid syntactic lightning bolts-sores in the spirit of the Flutter language :) -where there are problems with the "{} " characters, makes the code less readable.