Thoughts on the generation and handling of exceptions

Based on my personal experience, I developed a certain concept of working with exceptions. This concept is “sharpened” for applications based on business processes. For system and other programs, it may be ineffective. Because I mostly use .Net, then the examples of inclusions are given for the .Net platform.

The concept is presented in the form of a table:

The reason for generating the exception	Details	Exception class (.Net platform)	How to handle an exception
1. Violation of business process rules	Violations of any internal rules of your system. For example, an attempt to withdraw funds from an account with a zero balance. Moreover, the rules can be flexible: for some types of accounts you can allow to go to the negative.	You need to implement your class, the successor of Exception (previously recommended to inherit from ApplicationException, now changed). Usually, the exception contains useful information for the user.	Process according to the internal rules of your system. ') Most often, stop processing the current operation and issue a message to the user. These types of exceptions do not need to be written to the log file.
2. Incorrect data	2.1. Incorrect user input. For example, instead of a digit, a letter is entered.	If possible, handle without generating an exception (simple check or use TryParse). Otherwise, similarly 2.2.	Prompt the user what data is not correct. Provide an opportunity to fix them. It is not necessary to write to the log file.
	2.2. Incorrect data from the data source (Web-service, file, registry, database). For example, instead of the XML-format received plain text.	There are no clear rules. FormatException, InvalidDataException, etc. Usually, a special exception class is introduced into .Net that occurs when the data is incorrect. Examples: ConfigurationException, XmlException, SqlException, SqlTypeException, WebException. However, the occurrence of these exceptions does necessarily mean that the problem is precisely in the incorrect data (there are other reasons). But ArgumentException, InvalidOperationException, etc. may well apply. This greatly complicates the handling of the exception.	Two options: either the data provider violates the protocol, or the subscriber does not fully implement the data processing by protocol. If the data provider is not adequate - you can substitute a “crutch”. If your “crutch” was able to solve the problem, no need to write to the log file. Otherwise, write the details to the log file and solve the problem on one of 2 levels.
3. Incorrect code	3.1. Breach of contract.	IndexOutOfRangeException, NullReferenceException, AccessViolationException, ArgumentException, ArgumentNullException, ArgumentOutOfRangeException, InvalidCastException, etc.	Write the exception details to the log file, send the log to the developer. Such exceptions are 100% of the developer’s fault. Warn user about an error. Depending on where the error occurred, decide whether to close the program (if the data could be damaged). Correct the error in the code based on the log data and update the version of the program.
	3.2. Invariant violation.	InvalidOperationException
4. System error (often due to hardware problem).		Not removable: * ExecutionEngineException, StackOverflowException, OutOfMemoryException. In 99% of cases, it is not possible to process these exceptions.	In 99% of cases - do not handle. You can try to write these exceptions to the log.

I note that this structuring is based on basic concepts:

1. Hardware.
2. Software. In turn, software problems are divided into 2 subclasses: a data problem and a code problem.

So, in principle, I did not invent anything new.

It is worth noting that the errors of one category can exclude exceptions of another category. For example, incorrect code may cause a StackOverflowException. Although, incorrect data ideally should not cause incorrect code errors or system errors.

I would like to hear thoughts on the topic.