Welcome to MSDN Blogs Sign in | Join | Help

Jesper's blog about integrating with Office Accounting

This blog discusses how to write applications that integrate with Office Accounting.
Catching exceptions from the loader

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:

ISmallBusinessInstance smallBusinessInstance;

IFormsFactory formsfactory;

 

try

{

    ISbaObjects sbaObjects = loader.GetSbaObjects(configurationFile);

 

    smallBusinessInstance = sbaObjects.SmallBusinessInstance as ISmallBusinessInstance;

 

    formsFactory = sbaObjects.FormsFactory as IFormsFactory;

}

catch (ApplicationException exception)

{

    if (exception is ILoaderException)

    {

        // Handle LoaderException

    }

    else

    {

        throw;

    }

} 

catch (TargetInvokationException exception)

{

    if (exception.InnerException is ISmallBusinessException)

    {

        // Handle SmallBusinessException

    }

    else

    {

        throw;

    }

} 

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.

 

Posted: Friday, November 03, 2006 10:27 AM by Jesper Birk Olsen

Comments

TAG said:

Why language does not allow us to do catch on interfaces ?

After all - it's simply a some algorithm that figure first possible catch block that must be executed to react on object thrown.

In case of tie in same try/catch/catch block - use one that comes first in source code.

# November 4, 2006 5:34 AM

Jesper Birk Olsen said:

Hi

Sorry but I don't know the specific reason for this.

The compiler will show an error "The type caught or thrown must be derived from System.Exception" if you try to compile a catch of an interface.

here's a link where you can read a little about the error: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cscomp/html/vcerrCompilerErrorSC0155.asp

Otherwise you could try other MSDN resources which are more specific to the .Net framework and error handling.

Thank you

Jesper

# November 7, 2006 2:01 PM
Anonymous comments are disabled
Page view tracker