There are certain scenarios where I just want to call a certain method to do some work and don't care about handling all specific exceptions it can throw. Instead, all I really care is if the method succeeded or not.
I will provide a .NET / C# example. Let's say I have a file that I want to copy and all I really care is whether copy operation was successful or not. If copying failed I don't care if particular exception was FileNotFoundException or an IOException "Not enough disk space" exception or something else... My application will move on normally in that case as this operation is not critical.
So the idea how to implement this is:
try
{
// try
System.IO.File.Copy(strFile, strFile + ".new");
}
catch (Exception ex)
{
// if critical exception then rethrow
if (IsCritical(ex))
throw;
// else just log and swallow...
Console.WriteLine("Failed to copy the file: " + ex.Message);
}
where IsCritical(Exception ex) is helper method defined as:
public static bool IsCritical(Exception ex)
{
if (ex is OutOfMemoryException) return true;
if (ex is AppDomainUnloadedException) return true;
if (ex is BadImageFormatException) return true;
if (ex is CannotUnloadAppDomainException) return true;
if (ex is ExecutionEngineException) return true;
if (ex is InvalidProgramException) return true;
if (ex is System.Threading.ThreadAbortException)
return true;
return false;
}
This question is based on following article: Exception Handling in C# with the "Do Not Catch Exceptions That You Cannot Handle" rule in mind
The idea is to follow the main rules of exception handling best practices: - don't catch general Exception without rethrowing - catch only exceptions you know how to handle - (in this case I want to handle them all in the same way... by logging and moving on with the application logic).
So is this a good approach for the given scenario? If not, why and what would be better thing to do?
The reason it is generally advised to not swallow exceptions is that it can hide bugs. For example, you are doing something other than doing a File.Copy
: you are doing string processing as well (strFile + ".new"
). This cannot throw (except for OOM), but if the calculation was more complex, you might have hidden a bug.
In this case you should probably move all calculations out of the try-block. Then it is OK to swallow any exceptions. I'm in the habit of logging them in case I still made a mistake despite being careful.
The rule to not swallow needlessly is there to protect the developer from his own fallibility. If you are reasonably sure that everything is alright then you don't need to follow the rule.
This line worries me a little...
If copying failed I don't care if particular exception was FileNotFoundException or an IOException "Not enough disk space" exception or something else
Not so much the FNF exception but more with the "Not enough disk space" etc. - these are the sort of exceptions you probably don't want to ignore. Reason being, if there isn't enough disk space then, in theory, your app is going to fail eventually. This is actually one of the main reasons you shouldn't catch general exceptions because you effectively mask bigger problems like these.
On a more general note, and to answer your question more specifically, it's perfectly fine to catch a more general exception where you are confident it won't have any major implications with your app nor, as mentioned previously (and I re-iterate for good reason), won't mask any bigger/more serious issues.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With