An exception is C# telling you that a method could not do what its name says. The language gives you three keywords and a type hierarchy, and almost every argument about exception handling comes down to one question: which failures are worth catching where you are standing.
The articles here answer that from both ends. Some are about the mechanics, which are small and quickly learned. The rest are about the two exceptions every C# developer meets first, and about the habits that stop a catch block from swallowing the thing you needed to know.
If you are here because of a specific message, the two named exceptions have their own articles and both start with what actually caused it.
The Exceptions You Meet First
Two exceptions account for a large share of the crashes in new C# code. Both have a cause that is easy to see once you know where to look.
try, catch and throw
The mechanics. Short articles, and the throw versus throw ex one is worth reading even if you think you know the answer.
- Catch Multiple Exceptions
- Exception Handling
- Difference Between "throw" vs "throw ex"
- Using the when Keyword in C# While Handling Exceptions
Handling Exceptions Across an Application
Catching in one place instead of in fifty, and getting told when it happens in production.
- Global Exception Handling for MediatR Requests
- Real-Time .NET Error Reporting With Exceptionless
- How to Use IExceptionHandler to Handle Exceptions
Cleanup and Recovery
Releasing what you took, and deciding whether a failure is worth trying again.
Testing Exceptions
Proving the failure path behaves, in all three test frameworks.
Where to Go Next
The topics exception handling touches most often:
A catch block that cannot fix anything is usually a log statement in disguise. Let the exception travel until it reaches code that can actually make a decision about it.
