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 exc
Documentation will often describe what exceptions a method might throw and the conditions under which that might happen. This is especially the case with Microsoft's reference documentation for the .NET framework.
In my view, exceptions should only be caught if you have a good reason to catch them. This usually means that catching and handling them in a generic manner is unnecessary. Logging exceptions (a very common activity in an exception handler) should only happen at the bottom of the call stack or whenever you don't rethrow the (possibly wrapped) exception , which should be rare. If you have some action you want to take place at every frame in the call stack when an exception is bubbling down, take a look at Aspect Oriented Programming (AOP) techniques.
IMO - don't catch any exception unless you plan to add value to it and/or it can be handled in that method only.
Please do have a common exception handler which handles all un-handled exceptions.
HTH.
The bigger question is if you need to do specific error handling on specific exceptions. If you just need to catch any errors that occur, there is nothing wrong with just making a generic try/catch block:
try
{
// Some Code
}
catch
{
}
However, if you need do specific handling on certain exceptions, you can specify multiple catch blocks per a single try:
try
{
// Some Code
}
catch(ArgumentException argE)
{
}
catch(NullReferenceException nullE)
{
}
catch(Exception e)
{
// Everything else
}
If you can't recover from an exception, don't catch it at that level.
You should catch those exceptions for which you can develop a reasonable strategy to deal with the problem. There's no point in catching an exception if there's no reasonable alternative (trying again later, using a different technology/technique to achieve the same overall goal, informing the user that the goal cannot currently be achieved and what they can do to remedy the situation).
Exception (pardon): It is worth having something at the very top level (e.g. Application.ThreadException or AppDOmain.UnhandledException) to attempt to log those exceptions that you haven't handled. If logging fails, you're doomed anyway.
But blindly swallowing all exceptions (especially at a low level) can lead to very frustrating debugging/diagnostic sessions.
The methods you run will generally show what exceptions can be thrown. You can then catch accordingly.
If it's your own code, you can generally see what will be thrown, or use the underlying classes exceptions as a guide on what you will need to catch.
I recommend a few links: