Before you write a try…catch, answer three questions:
1 Do you know exactly which exception will be thrown?
Not something might go wrong. A specific type. A specific failure mode. If you are catching System.Exception, you are not handling. You are guessing.
2 Do you know what to do when you catch it?
Not log and continue. An actual recovery action. Retry? Fallback? Re-validate state? If your catch block has no meaningful response, it should not exist.
3 Can you validate the state before the call instead?
Most exceptions at external boundaries (APIs, databases, file IO) can be reduced with defensive checks before the call. If you can validate, do that. Try…catch is a last resort.
If you cannot answer yes to all three, remove the try…catch.
Set up a global exception handler instead. Let the crash happen. Log everything. Fix the root state.
That is how you get a codebase that actually becomes more stable over time, not one that silences failures until they are impossible to find.
Which of the three is hardest to get developers to follow?