When is it justified to create a new exception. Is there some kind of checklist with conditions to be met before it is a good design decision to make a new exception type with respects to the .Net framework?
For example consider:
You have a class with a method that return an integer that is not critical to be completed by the consumer of the method but provide some extra information. There are various things that could go wrong in the method that does not depend on how the user of the class calls this method. Let say one is that network connection could be lost and the other is that the API of the web service the method is trying to call changed. The consumer of the method do not have the ability to handle these cases differently to try recover from the exception. Should there be two different exceptions for these operations or a more general exception (say for example CommunicationFailureException) covering both these cases with a specific description and inner exception? Or should the .Net exceptions be thrown that was originally thrown when the method failed to call into the web service?
I would appreciate more to know the principles for creating a new exception type rather than something to just cover this specific example.
Create a new exception type when you have something additional to say about the exception – something that is not covered by the existing exceptions.
If your application has some specific invariants and you need to communicate they are invalid – that may be a good place for a custom exception type. This allows you to catch exceptions that are specific to your application.