In many situations, if you want to recover from an exception, you need the details on what caused it - that usually involves creating your own exception classes and proving your details as properties. To use the most basic example, an ArgumentOutOfRangeException
contains a property ActualValue
, which you might read off and decide what to do based on the value you get.
When using contracts, if your contract fails, you'll just be given a basic ContractException
, which is compiler generated, and only contains details about the contract failure in string form, which may need some complex parsing in order to extract what you want from it - you generally wouldn't bother doing that.
If you're using your own exceptions, there should be no reason to keep the contracts in there at runtime, because they'll never be reached if they are about to fail - you'd just be wasting instructions on nothing.
Using static-contract checking alongside your own exception checking is the most effective form of eliminating errors. Most of the time, your exceptions will never be thrown because you're told how to fix the problems before running your app.