I’ve gotten in the habit of using a general catch statement and I handle those exceptions in a general manner. Is this bad practice? If so, how do I know which specific exceptions could be thrown and which ones do I catch?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I’ve gotten in the habit of using a general catch statement and I handle those exceptions in a general manner. Is this bad practice? If so, how do I know which specific exceptions could be thrown and which ones do I catch?
Yes, except in a couple of very specific cases that’s bad practice. The one common case I can think of where catching all exceptions isn’t a lousy idea is when you’re logging a message or a stack trace just before the app is about to tear itself down (or, maybe, you’re logging and rethrowing).
Catch only the exceptions you know you can handle. No more, no less. If you don’t know an exception can be thrown from a method, you aren’t going to handle it properly anyway so don’t catch it. Methods and libraries are responsible for documenting exceptions that you should be able to handle. Also, don’t catch exceptions that indicate a logic failure, such as
NullReferenceExceptionandArgumentException. These indicate a genuine bug in your software that you should fix, not something that you should handle at runtime.