Error handling refers to run-time errors. You can't handle compile-time errors with error handling, since executing the error handling requires compiling and running the code in the first place.
What you can do, is change how you're compiling your code. For example, this code requires a compile-time reference to MyLibrary
:
Dim foo As MyLibrary.Something
This code doesn't:
Dim foo As Object
The difference is that member calls against foo
are no longer resolved at compile-time - which means you can't get intellisense when coding against it; VBA will happily compile a typo and run-time will blow up with error 438 saying it can't find the specified member.
foo.DoSomething 'works if foo has a DoSomething member.
foo.IDontExist 'compiles but throws error 438 at run-time.
When your project has a reference to MyLibrary
, you're early-binding - meaning code will refuse to compile if, say, the DLL can't be found.
When your project doesn't have a reference to MyLibrary
, and your code doesn't include any identifier that's defined in that library (Option Explicit
becomes utterly important then), you're late-binding - meaning the compiler will not care to validate the member calls, and the linking happens at run-time.
Converting your early-bound code to late-bound code will require extensive overhaul of every single declaration, replacing every single class with Object
, then removing the references to the DLL's.
Then you can't do this anymore:
Set foo = New MyLibrary.Something
Instead, you use the class' registered ProgId
(a GUID works too) to locate the DLL at run-time by hitting the Windows Registry entry for it, using the CreateObject
function:
Set foo = CreateObject("MyLibrary.Something")
If the MyLibrary.Something
ProgID isn't registered on the machine the code is running on, a run-time error will occur, that you can handle at run-time with classic On Error
statements. The correct ProgID values to use depend on how the DLLs were registered; they may or may not match the "Library.TypeName" scheme.