Question

As it is, I tried error-proofing my code and ended up making it look quite messy.

I have a function set up to read a certain type of file. I want the function to return false if there was a problem, or true if everything worked. I’m having trouble figuring out how to structure everything.

I have an initial try-catch block that tries to open a file stream. After that though, I have certain other checks I make during the reading process such as file size and values at certain offsets. The way I set it up was with if else statements. Such as:

if(condition){

}
else{
    MessageBox.Show("There was an error");
    br.Dispose();
    fs.Dispose();
    return false;
}

…br being the binary reader and fs the filestream. There are many blocks like this, and it seems like bad practice to write the same thing so many times. The first thing that comes to mind is to wrap the entire thing in a try-catch statement and throw exceptions instead of using the if else blocks. I remember when reading about try-catch statements that it’s good to have them, but not to wrap everything with them. To be honest, I still don’t completely understand why it would be bad practice to wrap everything in try catch statements, as they only have an effect when there’s an error, in which case the program is going south anyway…

Also, do I have to close the binary reader and file stream, or will closing one close the other? Is there any way to use them without having to dispose of them?

Answer 1

How about making use of the using keyword? this wraps your use of an IDisposable in a try – finally block;

bool success = true;

using(var fs = new FileStream(fileName, FileMode.Create)))
using(var br = new BinaryReader(fs))
{
  // do something
  success = result;
}

return success;

The nested using blocks will ensure that both the filestream and binary reader are always properly closed and disposed.

You can read more about using in MSDN. It makes the use of IDisposable a little neater, removing the need for explicit excpetion handling.

Regarding your statement:

I remember when reading about try-catch statements that it’s good to
have them, but not to wrap everything with them.

I always use the simple rule that if I cannot handle and recover from an exception within a particular block of code, don’t try to catch it. Allow the exception to ‘bubble up’ the stack to a point where it makes more sense to catch it. With this approach you will find that you do not need to add many try-catch blocks, you will tend to use them at the point of integration with services (such as filesystem, network etc …) but your business logic is almost always free of exception handling mechanisms.