Guarding against exceptions (preventative maintenance) when working with network / file system calls?

Question

I have a friend who is in disagreement with me on this, and I'm just looking to get some feedback as to who is right and wrong in this situation.

FileInfo file = ...;

if (file.Exists)
{
    //File somehow gets deleted

    //Attempt to do stuff with file...
}

The problem my friend points out is that, "so what if the file exists when I check for existence? There is nothing to guard against the chance that right after the check the file gets deleted and attempts to access it result in an exception. So, is it even worth it to check for existence before-hand?"

The only thing I could come up with is that MSDN clearly does a check in their examples, so there must be more to it. MSDN - FileInfo. But, it does have me wondering... is the extra call even worth it?

Addict

I more or less agree with your friend. In order to make the code robust, you should be trapping for the exception, which makes the file.Exists bit redundant. On the other hand, if I were processing a large number of files, many of which might be absent, I might stick the file.Exists bit in there to avoid the overhead of triggering the exception-handling mechanism. – Oh

Remember that there is no cost in performance to have any exception block with no thrown exception, which is hard ague against not using exception handling especially in the case of files. Otherwise, you are talking milliseconds between check and call. – Jerky

Answer 1

I would have both if (file.Exists) and a try catch. Relying only on exception handling does not express explicitly what you have in mind. if (file.Exists) is self-explaining.

If someone deletes the file just in that millisecond between checking and working with the file, you can still get an exception. Nevertheless, there are also other conditions, which can lead to an exception: The file is read-only; you do not have the requested security permissions, and more.

Berthaberthe

Answer 2

I agree with your friend here for the most part (context depending on whether or not you have withheld pertinent information from your question). This is an example of an exception that can occur outside of your magnificent code. Checking for the existence of the file and performing your operation is a race condition.

The fact is that this exception can occur and there is NOTHING you can do to prevent it. You must catch it. It's completely out of your control. For example, what if the network goes down, lightning strikes your datacenter and it catches on fire, or a squirrel chews thru the cables? While it's not practical to try and figure out every single way in which the code will raise an exception, it is a good practice to do your best in situations where you know it's a good possibility and do your best to handle it.

Maritime

Answer 3

I would say this depends on the context. if the file was just created and then this process ran, then it doesn't make sense to check if it exists. you can assume that it does because the code is still executing.

however if this is a file that is continuously deleted & created, then yes it does make sense to ensure it exists before continuing.

another factor is who/what is accessing the file. if there are multiple clients accessing the file then there is a greater chance of the file being modified/removed and therefore it would make sense to check if the file exists.

Segarra