tags:

views:

52

answers:

2

Why did microsoft's API team recreate an Exception class in Microsoft.Office.Interop.Outlook that would conflict with the System Namespace's Exception class?

Does it have to do with the unmanaged nature of interacting with the Office Suite? Why should it be used instead of System.Exception?

+1  A: 

This is an automatically generated wrapper around the Outlook COM library's Exception class, which represents an exception to a recurring appointment.

The types in the Office PIAs are thin wrappers around the corresponding native COM libraries and do not follow standard .Net conventions; this is why Office automation is so annoying in C# < 4.0.

For example, collection classes are pluralized (eg, Columns instead of ColumnCollection), many properties are parameterized (which are not supported by C# < 4), most method parameters are ref objects, and many events share the same name as a method (eg, Document.Close in Word).

The VSTO Power Tools make Office automation in C# much easier.

SLaks
A: 

According to the docs for Outlook.Exception it seems to be a readonly object that can't be created by you but can only be thrown by internal Outlook code, so I'd say ignore it and use normal Exception but be prepared to handle Outlook.Exception if you're creating appointments.

Since they're in different namespaces it's not really an issue anyway.

ho1
It is if you have `using Microsoft.Office.Interop.Outlook;` then any reference to `Exception` has to be either `System.Exception` or you have to declare `using Exception = System.Exception;` in-order for the compiler to know which Exception class you're using.
Malfist
@Malfist: Yes, but that's just adding a little extra text. Otherwise it's quite common for people to alias the office interop libraries just to make things clearer, so it would be `using Outlook = Microsoft.Office.Interop.Outlook;` and then you'd use `Outlook.SomeClass` everywhere and you're sure nothing will interfere with the framework namespaces you're using.
ho1