views:

90

answers:

2

As an example, assume the following snippet of VB.NET code to delete a directory.

 Try
      Dim SomeFolder="c:\somefolder"
      System.IO.Directory.Delete(SomeFolder, True)    
 Catch ioex As System.IO.IOException     
     'What went wrong? 
     'File locked by another process? 
     'File not found? 
     'something else?
 End Try       

In the exception handler, if the directory or a file inside it is open I'd like to give the user the opportunity to close the file and retry the operation, but only if the IOException was caused by a locking problem.

The problem is that the IOException can be thrown for any number of reasons, for example an invalid path or read-only flag set on the file. Each of these conditions sets a different value in the .message attribute of the exception object, but it just feels so wrong to hard-code a check for a specific string in the error message to detect the specific cause of the failure. I don't have a lot of confidence that the error strings will be consistently worded with future versions of .net and would hate to have to fuss about with writing localization code to deal with the possibility that the message is returned in something other than English.

There has got to be a better way to deal with what has to be an extremely common exception handling concern. Am I missing something?

Update/Clarification: Thanks for the answers so far, but I may have made my example a little too generic. For right now at least, I am specifically looking for a way to detect the condition of the file being locked by another process within the exception handler.

+5  A: 

You can catch some of the exceptions that inherit from IOException.

These include DirectoryNotFoundException, FileNotFoundException and others.

Use Exception Handling for this:

Try
  Dim SomeFolder="c:\somefolder"
  System.IO.Directory.Delete(SomeFolder, True)    
Catch fnfex As System.IO.FileNotFoundException     
 'What went wrong? 
 'File not found? 
Catch ioex As System.IO.IOException     
 'What went wrong? 
 'something else?
End Try       

Update:

With file operations, it would be better to test for the existence of the file/folder before operating on it. This is best practice, as you avoid unnecessary exceptions:

Dim SomeFolder="c:\somefolder"

If Directory.Exists(SomeFolder) Then
   System.IO.Directory.Delete(SomeFolder, True)
End If

Update 2:

Following the comments and the update to the question regarding locked files. I have had the same problem and did resort to parsing out the exception message, as there is no FileLockedException or similar :(

Oded
You actually want `DirectoryNotFoundException`.
SLaks
Good call, but the condition I am most interested in is when the file is locked by another process, and I'm not seeing a IOException subclass that addresses that specific condition. The framework is just returning a generic IOException object in this situation.
JohnFx
Regaring your update: It's best practice, but of course it shouldn't *replace* proper exception handling because the file might have been deleted/moved meanwhile.
0xA3
updated the question again: I'm looking for a way to definitively know in the exception handler that the problem was a locked file.
JohnFx
FYI: Structured Exception Handling (SEH) is a Windows operating system mechanism for signaling error conditions, and is not the same as the multiple `Catch` blocks in the VB.NET code you posted. (Unless you meant that SEH exceptions get wrapped into .NET Exceptions by the CLR, but if that's what you meant then your text is not very clear.)
Daniel Pryden
+3  A: 

The better option is to do your checks up front rather than rely on exceptions. For instance:

if (Directory.Exists(SomeFolder))
{
    Directory.Delete(SomeFolder, true);
}

That way you at least attempt to reduce many reasons the IOException could be thrown for.

Edit: Not saying that my option removes the needs for exception handling, just that it makes them true exceptions rather than just part of the normal program flow.

Update: So from the comments the example from the OP doesn't lend itself well to the idea I'm trying to present. The point I'm trying to make is that it's better to check for possible exceptions before they except when you can. For instance:

if (object != null)
{
    object.Value = true;
}

is a better option than a huge overloaded catch like (example simplified):

try
{
    object.Value = true;
}
catch NullRefrenceException
{
    ...
}
catch Exception
{
    ...
}

Edit: Regarding the OP's update about file locks. I don't believe there is a more specific expection that get's thrown here so parsing the message is probably your only option. Unless you can find someway to check for a lock up front without an exception. Even then the lock state could change between your check and attempt to access.

Cory Charlton
Unless the directory is deleted by someone else before the call to our `Directory.Delete`.
João Angelo
Yes not much you can do about that. Not saying that my option removes the needs for exception handling, just that it makes them true exceptions rather than just part of the normal program flow.
Cory Charlton
This in fact does not eliminate Direct.Delete throwing an exception for a deleted directory. Another program can easily delete the file inbetween the call to Exists and Delete. http://blogs.msdn.com/jaredpar/archive/2009/12/10/the-file-system-is-unpredictable.aspx
JaredPar
@Cory: I agree with you, but by not removing the need for exception handling the OP would still be having the problem described.
João Angelo