the software responsible for allowing c# and .net to work with COM is known as COM interop. Its part of the .net sdk. more specifically, tlbimp.exe.
tlbimp.exe interprets the API in a COM type library and wraps it up for .net. One of the things it does, is intercept HRESULT values and throw exceptions from them, which is a more .net way of doing things. So you will find that rather than check the HRESULT, you can try/catch the error instead.
look to this page for more information
http://msdn2.microsoft.com/en-us/library/awy7adbx.aspx
in a coding purist's mode of thinking this is either good or bad. Certainly debatable. One theory of passing error conditions as return values rather than exceptions is based on the concept that throwing an exception is usually a much heavier task than simply returning a result to a normal function call. Therefore, programs that are depending on frequent error conditions for flow control will run faster communicating those errors as return values, than as exceptions. However, it is likely that COM does this, not for performance, but to avoid having to find a way to make exceptions cross the COM boundary between languages. COM in general however, is so slow, I'm not so sure the performance hit is of any real consequence.