How can I clean this up?

std::wstring LinkResolve::ResolveLink( const std::wstring& source ) const
{
HRESULT errorCheck;
wchar_t expandedTarget[MAX_PATH];
wchar_t arguments[INFOTIPSIZE];
ATL::CComPtr<IPersistFile> ipf;
if (!SUCCEEDED(errorCheck))
{
throw _com_error(errorCheck);
}
if (!SUCCEEDED(errorCheck))
{
throw _com_error(errorCheck);
}
if (!SUCCEEDED(errorCheck))
{
throw _com_error(errorCheck);
}
if (!SUCCEEDED(errorCheck))
{
throw _com_error(errorCheck);
}
if (SUCCEEDED(errorCheck))
{
return std::wstring(expandedTarget) + L" " + arguments;
}
else
{
return expandedTarget;
}
}

• This makes me think of Haskell's maybe monad, but I don't think that will help you. Still this would totally work with it. – Theo Belaire Jan 28 '11 at 20:14
• @Tyr: Or C++14's optional<T>. :) – Billy ONeal Jun 28 '13 at 6:29

Personally, I'd write a simple function:

void ThrowOnFail( HRESULT hrcode )
{
if (FAILED(hrcode))
throw _com_error(hrcode);
}


Then the function calls become:

ThrowOnFail( ipf.CoCreateInstance(CLSID_ShellLink, 0, CLSCTX_INPROC_SERVER) );


Incidentally, you missed a check for errorCheck after Load. This becomes easier to spot with a check function.

• Would it be possible, or reasonable, to merge the whole code block into one ThrowOnFail(...); including the CComPtr? That would reduce code duplication as well. Not extremely familiar with C++ and CComPtr. – WernerCD Jan 27 '11 at 13:58
• @WernerCD: No, that would not be possible. (Besides, with all those method calls you'd have a 500 character line!) – Billy ONeal Jan 27 '11 at 15:16
• Err... You know this is really why I shouldn't write code at 3AM :sigh:. – Billy ONeal Jan 27 '11 at 15:19
• Question: Does the error returned in this positively identify where the error came from? – Hack Saw Jan 27 '11 at 17:48

If I find my self writing the same thing over and over again I usually put it in a functiion somewhere. Even if that function in your case is as simple as this:

void check(HRESULT result) {
if (FAILED(result)) {
throw _com_error(result);
}
}


I think the code looks fairly straight forward if you reuse your error check code. I'm not familiar with the API that you are using, so I can't comment on if there is another way to use it that might result in cleaner code.

• May I ask you to replace !SUCCEEDED with FAILED? The latter evaluates exactly to the same as !SUCCEEDED. – sharptooth Jan 28 '11 at 6:35

At least when using DirectX, I use a macro.

#define D3DCALL(a) { auto __ = a; if (FAILED(__)) DXTrace(__FILE__, __LINE__, __, WIDEN(#a), TRUE); }


You could get fancier and use a type with an operator=(HRESULT) to make the check.

• Why an everywhere-reserved name for the local variable? I'd name it _local_D3DCALL (which is reserved in the root namespace scope but not elsewhere) or similar. This macro is a good candidate for calling an (inline) function, passing (a), __FILE__, __LINE__, and #a. – Fred Nurk Jan 27 '11 at 8:27
• No idea, it's been a long time since I wrote it, it's just a sample. – DeadMG Jan 27 '11 at 11:34
• Some macros just for you! -> codereview.stackexchange.com/questions/281/… :) – Billy ONeal Jan 27 '11 at 15:51

I remember seeing something like this before:

class XHR
{
public:
XHR() {};
~XHR() {};

operator HRESULT() { return hr };

HRESULT& operator =(const HRESULT& rhs)
{
hr = rhs;
if (FAILED(hr)
throw _com_error(hr);
}

private:
HRESULT hr;
}


Then you can write:

std::wstring LinkResolve::ResolveLink( const std::wstring& source ) const
{
XHR errorCheck;   // instead of HRESULT errorCheck

wchar_t expandedTarget[MAX_PATH];
wchar_t arguments[INFOTIPSIZE];
ATL::CComPtr<IPersistFile> ipf;

try {
return std::wstring(expandedTarget) + L" " + arguments;
}
catch (const XHR&)
{
return expandedTarget;
}
}


So anytime an HRESULT that indicates failure, it will automatically convert it into a _com_error for you, and throw it.

• This is interesting (therefore I will +1 you), but if you were to ignore the type of errorCheck it would look as if you were ignoring errors. I think I would favor an approach that seems more explicit if you are looking at statements and merely glancing over the types. – asveikau Jun 14 '11 at 8:54

Error checks are not all the same. sometimes you act upon special returned HResults. sometimes there is an ELSE. sometime you want to log the error,sometime you don't..

Also - although highly unlikely to be relevant in the com/atl world - calling a function has it's performance costs.

so I prefer using if after the call, rather than calling a function. How much do you save ? typing 10 chars ?

• The example in the question is very clear that it's the same code over and over. Not functionalising it merely creates a maintenance headache. Should the need arise to handle a specific case differently then you write specific code for it. But to use that as an excuse to not write the general function in the first place is inefficient and IMO ill-advised. – LRE Jan 27 '11 at 8:24
• if this is c++, you can always set the method inline or use a macro with the same functionality – Pedro Loureiro Jan 27 '11 at 11:50
• Don't use a macro. You lose all type safeness. That's the reason for inline functions/methods. – Mark Loeser Jan 27 '11 at 14:06
• @MarkLoesser - There are times when macros are the right tool for the job. This is one of those times. The FILE and LINE expansions are very helpful in troubleshooting and would be lost if you used an inline function or method. – Jere.Jones Jan 27 '11 at 18:49

I think you can do much of the same by using Compiler com support here is an example.

#import "CLSID:lnkfile" //use the clsid of the ShellLink class.

IPersistFilePtr ptr = IPersistFilePtr.CreateInstance(...);


_com_ptr_t::CreateInstance() will throw an exception (of type _com_error if the call fails)

All other ifs in your code can be replaced by using the smart pointers generated by #import. I know I am a little skimpy on details but it has been a long time since I have touched COM.

• Not true according to this; _com_ptr_t::CreateInstance() seems to return a HRESULT, and has a throw () specification. – Billy ONeal Jan 27 '11 at 15:54