Professionalism, Craftsmanship, Discipline
The “try” bit in a try/catch block is cheap, it’s “catch” that hit’s performance because it has to set up a stack trace etc. So I use try/catch liberally where I don’t expect many catches. In some code, for example something that sits behind user interaction, performance is not an issue, so I don’t worry to much about try/catch blocks.
Where performance is an issue, inside loops or a heavily used back-end processes try/catch needs more consideration. With this in mind, here are my general rules for exceptions…
Create custom exceptions where they add meaning or clarity but avoid throwing custom exceptions where appropriate ones already exist.
When creating a custom exception always implement all of the base class’s constructors.
Custom exceptions should be sealed. Don’t subclass them.