The Loader implements a LoaderException class derived from ApplicationException similar to the way that SBA implements SmallBusinessExceptions.
Since the Loader is using reflection to call methods on the SBA objects themselves (like Logon and Initialize) it can throw both LoaderExceptions and TargetInvokationExceptions which wraps an inner exception as SmallBusinessExceptions.
Since calling applications should not be binding statically to the Loader assembly or SBA assemblies but only to the interface assemblies, they will need to catch ApplicationExceptions when using the Loader and then type cast it to ILoaderExceptions. In addition a calling application should catch TargetInvokationExceptions and check if the InnerException property is ISmallBusinessException thrown from the SDK.
Here's an example:
ISbaObjects sbaObjects = loader.GetSbaObjects(configurationFile);
smallBusinessInstance = sbaObjects.SmallBusinessInstance as ISmallBusinessInstance;
formsFactory = sbaObjects.FormsFactory as IFormsFactory;
catch (ApplicationException exception)
if (exception is ILoaderException)
// Handle LoaderException
catch (TargetInvokationException exception)
if (exception.InnerException is ISmallBusinessException)
// Handle SmallBusinessException
Notice that I use the "throw" here in order to not catch and hide exceptions I don't handle. Depending on your application that is often the best practise since your application cannot recover from system level exceptions anyway. If you catch-and-eat all exceptions you're basically in an unknown state after this code because you don't know if a serious exception like OutOfMemoryException was thrown - it would mean that the code would run out of memory at a random later stage (like when you later create a handle to a control) and you wouldn't know why.