Rethink about exceptions

 

He discussed exceptions with JGTM 2004 [MVP] Last time and said, "Use logical flow instead of exception capture as much as possible". I also agree

However, consider the following scenarios:

Transfer (Account from, Account to, int amount );

The above function is used to transfer funds between two accounts. If I find that the from account has no money, what should I do?

I found that the from account and to account are the same account. What should I do? In similar cases, do I use the return value to tell the caller? Obviously not suitable. In this way, it is back to the old path of structured programming. The caller has to make n + judgments ......

 

In Windows, Jeffery Richter tells us the answer: "throw an exception". Is that true?

According to his explanation, exceptions are a kind of violation of program interface assumptions.

 

Speaking of Jeffery Richter, I am also a little depressed, in his classic book (Applied Microsoft. NET Framwork) mentioned in the Exception chapter: In the design class library, we must strictly abide by the n-plus Exception handling principle he mentioned, but also said that application developers can completely deviate from these principles, to set your own policies. This is quite true. However, for example, if we want to develop both the data access layer and the business logic layer, there may also be the business appearance layer, which are class libraries and applications?

Which of the following principles should be used? The so-called application development and class library development are just relative concepts. Is it relative, but is my data access layer and business logic layer developed based on class libraries or applications ?!