As we’re talking about logging, don’t forget that you should always log
Exception.ToString(), and never
Exception.ToString() will give you a stack trace, the inner exception and the message. Often, this information is priceless and if you only log
Exception.Message, you’ll only have something like “Object reference not set to an instance of an object”.
Microsoft recommends that you should use return special values on extremely common situations. I know I just wrote the opposite and I also don’t like it, but life is easier when most APIs are consistent, so I recommend you to adhere to this style with caution.
I looked at the .NET framework, and I noticed that the almost only APIs that use this style are the APIs that return some resource (e.g.,
Assembly.GetManifestStream method). All those APIs return null in case of the absence of some resource.
Instead of “
throw ex;“, which will throw a new exception and clear the stack trace, we have simply “
throw;“. If you don’t specify the exception, the throw statement will simply rethrow the very same exception the catch statement caught. This will keep your stack trace intact, but still allows you to put code in your catch blocks.
An HRESULT is an opaque result handle defined to be zero or positive for a successful return from a function, and negative for a failure. Generally, successful functions return the S_OK HRESULT value (which is equal to zero). But in rare circumstances, functions may return success codes with additional information e.g. S_FALSE=0×01.
HRESULTS were originally defined in the IBM/Microsoft OS/2 operating system as a general purpose error return code, and subsequently adopted in Windows NT. Microsoft Visual Basic substantially enhanced the HRESULT error reporting mechanisms, by associating an
IErrorInfo object with an HRESULT error code, by storing a pointer to an IErrorInfo COM object in thread-local storage. The IErrorInfo mechanism allows programs to associate a broad variety of information with a particular HRESULT error: the class of the object that raised the error, the interface of the object that raised the error, error text; and a link to a help topic in a help file. In addition, receivers of an HRESULT error can obtain localized text for the error message on demand.
Subsequently, HRESULT, and the associated
IErrorInfo mechanism were used as the default error reporting mechanism in COM.
Support of the IErrorinfo mechanism in Windows is highly inconsistent. Older windows APIs tend to not support it at all, returning HRESULTS without any
IErrorInfo data. More modern Windows COM subsystems will often provide extensive error information in the message description of the IErrorInfo object. The more advanced features of the IErrorInfo error mechanisms—help links, and on-demand localization—are rarely used.
In the .NET Framework, HRESULT/IErrorInfo error codes are translated into CLR exceptions when transitioning from native to managed code; and CLR exceptions are translated to HRESULT/IErrorInfo error codes when transitioning from managed to native COM code.