A simple way to improve the quality of solutions

Probably every one of you has come across such solutions for SharePoint: the solution seems to work, but some problems constantly arise, data is not saved, strange drops during seemingly innocuous operations. Testers spend a lot of time on such a solution, but fixing some bugs causes others. To develop such a solution on a production farm is very difficult, support turns into hell. Familiar, yes?

Being engaged in the development of code analysis rules for the SPCAF ( http://spcaf.com ), I found a way to quickly fix this situation.


')
Find all the blocks of this type of code:

try { // } catch(Exception e) { //  ,  throw; } 

Enter throw; in the catch . It is important that the catch specifies the base Exception , and not the specific type of the exception.

Your application will start to fall and you will need to correct all the errors found without removing throw . I have already done this many times on different projects, and it gave a very positive result. Even if programmers resist, do not allow the throw .

Study

To test the rules, I collected about 70 .wsp files, SharePoint solutions. Most of them are projects in which I had the opportunity to participate, and I know very well all the problems that arose during development. I calculated the density of try\catch blocks without a throw and this is what happened:

• The most problematic solution is 1 block with 36 lines . That is, almost every significant method has been wrapped in such a try\catch .
• Solutions of average scall - 1 block for 90-100 lines . Some of these solutions have already carried out a try\catch cleaning.
• Good decisions - 1 block for 120-130 lines . There was never a problem with them.

Justification

Interception of all exceptions is not recommended almost always, Visual Studio Code Analysis swears at it, it is written in the Framework Design Guidelines. In the book Pragamtic Programmer, which is worth reading to all programmers without exception, the rule is short and succinctly formulated - Crash, don't Trash.

In fact, intercepting all exceptions is an attempt to suppress a mistake made by a programmer. The error still comes out, but not so obvious and, often, in a completely different place. This creates problems when developing solutions. This is especially true for SharePoint, since its API is extremely complicated.

I know only one case in SharePoint solutions when it is justified to catch all exceptions and not throw them further - in visual components, so that the developer’s error does not overwhelm the portal. But even they should consider handling specific types of exceptions, instead of intercepting everyone. In other cases, the code should fall as quickly and loudly as possible, preferably informing about what went wrong. There is no need to make any returns false or null in the case of an exception, let the code fall, then the developers and testers will see the error before the user sees it.

Conclusion

The problem of error suppression is relevant not only for SharePoint solutions and not only in C # and the .NET platform. Perhaps in other projects you can significantly improve the situation by removing the exclusion suppression.

Ps. The set of rules that checked solutions - http://spcafcontrib.codeplex.com/