Assume you have a very simple function and you wish to add some error trapping to it. The easiest way to go about it, is simply to include the regular calls to provided statements in Visual Basic. Here is a little example function to show how this would work. (Throughout this article I will reuse the same function and simply point out the hints with working with file handling too.)

This function will, on a call statement, load the desired file as a string, using the binary method for reading files. There is a very good reason to this choice of opening a file.

In older files, previously used for main frame systems, the character chr(26) was referred to as the EOF character. Reading a file for Input as an ASCII file would then throw a fit and claim that you have reached the EOF long before the EOF of the file is really there. By using a Binary method instead, you avoid this little obstacle in reading file data.

Besides, you are no longer limited to only opening ASCII files but can in fact open any file on your file system with this function, as long it is not locked by another program by the Lock Read, Lock Write, or Lock Read Write.

Refer to the Visual Basic help files "Open Statement" for further details on this behavior.

Public Function GetAFile(ByRef TheFile As String) As String
Dim F As Integer 

' get a free file number (always in the range 1 - 255)
F = FreeFile

'open the file in binary mode
Open TheFile For Binary As #F

'retrieve the Length Of File (file number) number of characters
'from file number F
GetAFile = Input(LOF(F), #F)

' close the file when your done
Close #F

End Function

By calling this function form a module or a form, you now have a string named GetAFile containing the full file you assigned to the call. Now this seems fairly simple enough, so what could possibly go wrong in this? Many things, for one, your file that you call for may perhaps not even exist. Now is the time you start bothering with questions like, "how do I check if a file exists?", or even "What API code will … ?". Highly technical solutions indeed, to a fairly simple problem.

The answer is… Err.Number 53

Lets break down the function step by step and look at the possible errors you could get.

Public Function GetAFile(ByRef TheFile As String) As String
Dim F As Integer 

' by not assigning F a FreeFile number you will receive error 52
' bad file name or number

' get a free file number (always in the range 1 - 255)
F = FreeFile

' by assigning TheFile a file name and path that doesn’t exists
' you will receive error 53 The file not found
''it could also be error 68, 70, 71, 75 or 76.
' also attempting to open a binary file in Input mode can
' throw an error 54 Bad file mode
'( you can't open binary contents in ASCII modes)

'open the file in binary mode
Open TheFile For Binary As #F

'By using the LOF function in a closed state you also receive error
'LOF and LOC functions only work on open files. Use FileLen(TheFile)
'if you wish to see the size in bytes of a file before it is open.
'LOF and FileLen returns LONG values

GetAFile = Input(LOF(F), #F)

'forgetting to close and re-assign a new value to F may throw a fit as well
' look at error number 55 File already open as one risk.

Close #F ' close the file when your done

End Function

To make a bad story less long and very simple, "Murphy's law" always apply and remember one thing in this. The computer will do exactly what you tell it to do. If it does something wrong, it is normally caused by your failing to provide proper instructions to it.

So how do we attempt to avoid all these little errors and glitches in a previously so simple and flawless code?

Lets break it down to a better version ad remove those warning comments.

Public Function GetAFile(ByRef TheFile As String) As String
' if something goes wrong send the function
' to my named range ErrHandler
On Error GoTo ErrHandler
Dim F As Integer 

F = FreeFile ' get a free file number (always in the range 1 - 255)
Open TheFile For Binary As #F 'open the file in binary mode
GetAFile = Input(LOF(F), #F)
Close #F ' close the file when your done

Exit Function ' if there was no error, don’t step further than here
ErrHandler: ' this is a named range called ErrHandler

' If there was an error raised by the function we would wind up in here 'so display a message to the user to show what went wrong

MsgBox "An error happened here!" & vbCrLf & _
"Error number: " & Err.Number & vbCrLf & _
"Error Description" & Err.Description & vbCrLf & _
"Error Help Context ID" & Err.HelpContext & vbCrLf & _
"Error Help File" & Err.HelpFile, vbCritical, "ERROR MESSAGE"

Err.Clear ' destroy the error and…
' … this resumes in the last known position.
' in this case, since its not more than a file opening occurring,
' it will simply exit the function for you.
Resume Next
End Function

As you see from this code, there is no direct definition to the source code to handle errors in any different way, it simply does what the run time files would do by it self anyway.

In order to refine the entire error handling somewhat more, you would have to include a more elaborate way of calling different error numbers to the screen by the use of a Select Case statement.

To demonstrate this I will only re-type the source code for the ErrHandler named range instead of the entire function. (It is a wild guess from my side but I think you have the hang of how to open a file in binary mode by now.)