Instead of calling these errors, there is a trend to call the exceptions (.net does this). After all, is "trying to write to a write protected floppy" an error or simply a system state that you may want to give the user a chance to modify?

Operating systems actually perform many functions for your programs (reading and writing files for example). When there is a failure, the operating system builds an object that describes the problem and raises an exception that is passed to your program. Then you have the option of

• Doing something with it
• Letting the operating system report it
• Ignoring it

On Error GoTo lable1 ' This is the normal way to define and enable
                     ' an error handler

On Error GoTo 0      ' Disables the error handling

On Error Resume Next ' Ignore future errors and continue with the next line


Exit_Point:
  Exit Sub     ' This is needed to make sure the error handler
               ' is not run when there are no errors.
               ' Use "Exit Sub", "Exit Function", or
               ' "Exit Property" as appropriate

Lable1:  'The error handler starts here

  Resume       ' Continue with the statement that caused the error
  Resume Next  ' Continue with the statement after the one that failed
  Resume lable ' Continue with the specified statement

  Resume Exit_Point


   ' Err is the built-in error object
if Err = someNumber then    ' Check fo a specific error
Err.Clear                   ' Clear the error
Err.Raise 4                 ' Force/simulate error 4

try
...
except
  on EDatabaseError do
  on ... do 
end;

try
 ...  // process file F
finally
  CloseFile(F);
  on ... do 
end;

Try
....
Catch
...
Catch ... when
...
Finally
...
End Try

URL: http:// cpcug.org / user / clemenzi / technical / Languages / CatchingErrors.htm