Error handling - which is preferrable?
-
I'm calling a method that can throw one of several exceptions:
byte[] ReadFile(string filePath)
{
return File.ReadAllBytes(filePath);
}When calling this method, do you guys usually catch every possible exception, or just cover it with a single catch block? For example, do you do this:
string errorMessage = null;
try
{
return File.ReadAllBytes(filePath);
}
catch (ArgumentException argumentError)
{
errorMessage = argumentError.Message;
}
catch (ArgumentNullException nullArgumentError)
{
errorMessage = nullArgumentError.Message;
}
catch (PathTooLongException pathError)
{
errorMessage = pathError.Message;
}
catch (DirectoryNotFoundException directoryNotFoundError)
{
errorMessage = directoryNotFoundError.Message;
}
catch (IOException ioError)
{
errorMessage = ioError.Message;
}
catch (UnauthorizedAccessException unauthorizedError)
{
errorMessage = unauthorizedError.Message;
}
catch (FileNotFoundException fileNotFoundError)
{
errorMessage = fileNotFoundError.Message;
}
catch (NotSupportedException notSupportedError)
{
errorMessage = notSupportedError;
}
catch (System.Security.SecurityException securityError)
{
errorMessage = securityError;
}if(errorMessage != null) { MessageBox.Show(errorMessage, ...); }Or do you catch it all in a single System.Exception catch block?
try
{
File.ReadAllBytes(filePath);
}
catch(Exception ex)
{
MessageBox.Show(ex.Message, ...);
}Obviously the latter is easier to read and write, but the former is more precise and won't eat up things like system errors (OutOfMemoryException, OverflowException, etc.). Which do you guys suggest?
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Little House on the Flickr Judah Himango<
-
I'm calling a method that can throw one of several exceptions:
byte[] ReadFile(string filePath)
{
return File.ReadAllBytes(filePath);
}When calling this method, do you guys usually catch every possible exception, or just cover it with a single catch block? For example, do you do this:
string errorMessage = null;
try
{
return File.ReadAllBytes(filePath);
}
catch (ArgumentException argumentError)
{
errorMessage = argumentError.Message;
}
catch (ArgumentNullException nullArgumentError)
{
errorMessage = nullArgumentError.Message;
}
catch (PathTooLongException pathError)
{
errorMessage = pathError.Message;
}
catch (DirectoryNotFoundException directoryNotFoundError)
{
errorMessage = directoryNotFoundError.Message;
}
catch (IOException ioError)
{
errorMessage = ioError.Message;
}
catch (UnauthorizedAccessException unauthorizedError)
{
errorMessage = unauthorizedError.Message;
}
catch (FileNotFoundException fileNotFoundError)
{
errorMessage = fileNotFoundError.Message;
}
catch (NotSupportedException notSupportedError)
{
errorMessage = notSupportedError;
}
catch (System.Security.SecurityException securityError)
{
errorMessage = securityError;
}if(errorMessage != null) { MessageBox.Show(errorMessage, ...); }Or do you catch it all in a single System.Exception catch block?
try
{
File.ReadAllBytes(filePath);
}
catch(Exception ex)
{
MessageBox.Show(ex.Message, ...);
}Obviously the latter is easier to read and write, but the former is more precise and won't eat up things like system errors (OutOfMemoryException, OverflowException, etc.). Which do you guys suggest?
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Little House on the Flickr Judah Himango<
It depends. For example, when reading a file I'll normally check it exists first, so I a PathTooLongException, DirectoryNotFoundException and FileNotFound are really things I should not be getting, so they'd be covered in a catch all (if at all at that point in the code). Specific things that I can't check for in advance would be in specific blocks. On the whole I find that exceptions propogate up a couple of method calls in the stack before I actually handle them because often at the point the exception occurs I am not able to handle it so I allow it to propogate up until I can do something about it. ColinMackay.net "Man who stand on hill with mouth open will wait long time for roast duck to drop in." -- Confucius "If a man empties his purse into his head, no man can take it away from him, for an investment in knowledge pays the best interest." -- Joseph E. O'Donnell
-
It depends. For example, when reading a file I'll normally check it exists first, so I a PathTooLongException, DirectoryNotFoundException and FileNotFound are really things I should not be getting, so they'd be covered in a catch all (if at all at that point in the code). Specific things that I can't check for in advance would be in specific blocks. On the whole I find that exceptions propogate up a couple of method calls in the stack before I actually handle them because often at the point the exception occurs I am not able to handle it so I allow it to propogate up until I can do something about it. ColinMackay.net "Man who stand on hill with mouth open will wait long time for roast duck to drop in." -- Confucius "If a man empties his purse into his head, no man can take it away from him, for an investment in knowledge pays the best interest." -- Joseph E. O'Donnell
-
It depends. For example, when reading a file I'll normally check it exists first, so I a PathTooLongException, DirectoryNotFoundException and FileNotFound are really things I should not be getting, so they'd be covered in a catch all (if at all at that point in the code). Specific things that I can't check for in advance would be in specific blocks. On the whole I find that exceptions propogate up a couple of method calls in the stack before I actually handle them because often at the point the exception occurs I am not able to handle it so I allow it to propogate up until I can do something about it. ColinMackay.net "Man who stand on hill with mouth open will wait long time for roast duck to drop in." -- Confucius "If a man empties his purse into his head, no man can take it away from him, for an investment in knowledge pays the best interest." -- Joseph E. O'Donnell
My example was simplified; my real code has the error propagating up a ways until it gets to the UI as well.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Little House on the Flickr Judah Himango