>I fire the WaitUntilFileIsReady from the FileSystemWatcher, so the file does indeed exist, but, you might be right that I should improve my code, for someone might get a hold of the file before my process and delete it, in which case my test will fail miserably for the while loop will be infinite. I changed my code to also check for the file existence in the while loop and also in the program that uses it. Thanks.

My final version is as follow:

    ' If a file is ready
    Public Function IsFileReady() As Boolean
        Dim lcFile As String = ""
        Dim llSuccess As Boolean = False

        ' Reset the values
        lIsFileReady = False

        ' Initialization
        lcFile = Trim(cFile)

        ' If the file is empty
        If lcFile.Length = 0 Then
            cMessage = cYouNeedToDefineTheCFileProperty
            Return False
        End If

        ' If the file can be opened for exclusive access it means that the file is no longer locked by another process
        Try

            ' Try to open the file for exclusive access
            Using loFileStream As System.IO.FileStream = System.IO.File.Open(lcFile, _
             System.IO.FileMode.Open, System.IO.FileAccess.Read, System.IO.FileShare.None)

                ' If we have a stream
                If loFileStream.Length >= 0 Then
                    lIsFileReady = True
                End If

            End Using

            llSuccess = True
        Catch loError As System.Exception
            cMessage = loError.Message
            llSuccess = True
        End Try

        ' Reset the values
        cFile = ""

        Return llSuccess
    End Function

The goal I am following is to always have a return for a method which represents the success of its operation. Then, I rely on a property to see if a specific flag is on or off. However, in this case, because the Using will fall into the Catch if the file is not ready, which could be a normal behavior in specific circumstances, it still denotes that the method did in fact operate with success.

So, as you can see, exceptionnally in this case, I have a llSuccess = True in the Catch as well. This is what happened earlier on with my test.

But, having this design allows me to return false assuming the file would not exist. So, if I recognize a False in the client application, it means something is not normal as if I go in here this is because there should be a file. In that case, the client application would then log an error.

So, this leaves the place for more validation. One of them, as mentioned, would be to verify for the existence of the file. In my case, I only have a detection to make sure I passed something for the cFile property.