Reporting Exceptions Well in Visual Studio
Microsoft has some "best practice" advice to share on how to handle exceptions (a topic I've discussed elsewhere). The Microsoft article is well worth reading ... but there's one piece of advice that I disagree with (talk about hubris, eh?).
One of Microsoft's recommended practices is that you should prefer to throw a built-in Exception class rather than your own, custom Exception class. The problem I see with this is that the built-in Exception objects return, at best, the technical reason for the exception (for example, "Division by zero"). Creating your own exception object allows you to specify the business reason for the failure (for example, "Customer has no sales orders").
Personally, I think that the message with the business reason is more useful both to the user faced with the message and the developer who has to fix the problem. Instead, I recommend using a custom exception object and tucking the original Exception into your custom Exception object's InnerException property. That gives you the best of both worlds.
Posted by Peter Vogel on 04/26/2019