开发者

Is there a reliable way to discern IOexceptions caused by locked files other than parsing the .message attribute?

开发者 https://www.devze.com 2022-12-19 11:04 出处:网络
As an example, assume the following snippet of VB.NET code to delete a directory. Try Dim SomeFolder=\"c:\\somefolder\"

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开发者_C百科, 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.


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 :(


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.

0

精彩评论

暂无评论...
验证码 换一张
取 消