We're all aware how painful it can be when you see a nasty error message. In the best case it makes you feel uneasy and at worst it leaves you blocked.
The user experience should not be an incredibly jarring jumble of text that looks like it is designed for a computer đ¤˘. On the other hand, a developer should not be developing new features when they are oblivious to the unhealthy state of the application.
For developers, it is crucial to log errors, watch them daily and review the health of the application in the Sprint Review.
Let's jump in and look at some of the best practices.
When developing software, exceptions are a fact-of-life you will need to deal with. Don't reinvent the wheel, use an existing exception handling library or service.
The best exception handling libraries are:
Your users should never see the âyellow screen of deathâ. Errors should be caught, logged and a user-friendly screen displayed to the user.
Did you know that writing your own logging infrastructure code wastes time? There are awesome logging abstractions in .NET Core and .NET 5+ that you should use instead!
A good catch and re-throw will make life easier while debugging, a bad catch and re-throw will ruin the exception's stack trace and make debugging difficult.
Catch and rethrow where you can usefully add more information that would save a developer having to work through all the layers to understand the problem.
In a try-catch block, avoid catching generic Exception types as this masks the underlying problem. Instead, target only the specific exceptions you can manage, which helps in accurately identifying and rectifying the error.
It is essential to foresee the exceptions that the code in the try block might raise. Catching these specific exceptions at the point of occurrence provides the most context for effectively addressing the issue.
While everyone knows that
catch (Exception ex)is bad, no one has really noticed thatÂthrow new Exception()is worse.System.Exceptionis a very extensive class, and it is inherited by all other exception classes. If you throw an exception with the codethrow new Exception(), what you need subsequently to handle the exception will be the infamouscatch (Exception ex).The ability to see the overall health (performance counters, exceptions, data usages, page hit counts etc.) of your application ensures you are well in control of it and have all the necessary information at your hands to action any bugs or performance issues. An analytics framework allows you to do all of that in a consistent and centralised manner.
Code auditing is an essential practice that empowers developers, quality assurance teams, and organizations to identify and rectify potential flaws, weaknesses, and security risks within their codebase.
SSW Code Auditor is the perfect tool to audit your code helping you find:
- Broken links
- HTML errors
- Google Lighthouse issues
- Do you use the best exception handling library?
- Do you present the user with a nice error screen?
- Do you use the best trace logging library?
- Do you catch and re-throw exceptions properly?
- Do you catch exceptions precisely?
- Do you know that you should never throw an exception using System.Exception?
- Do you use an analytics framework to help manage exceptions?
- Do you know how to manage errors with Code Auditor