Возвращать недокументированные HRESULTS из стандартных методов интерфейса COM? - PullRequest
Новая
       46

Возвращать недокументированные HRESULTS из стандартных методов интерфейса COM?

1 голос
/ 27 июня 2011

Каково правило возврата недокументированных HRESULTS из документированных стандартных объектов COM?

Я смотрю документацию для IObjectWithSite.SetSite, в которой говорится, что я должен вернуть S_OK в во всех ситуациях:

Синтаксис
HRESULT SetSite(IUnknown *pUnkSite);

Параметры
- pUnkSite : [in] Указатель интерфейса на сайт, управляющий этим объектом. Если NULL, объект должен вызвать IUnknown :: Release , чтобы освободить существующий сайт.

Возвращаемое значение
Возвращает S_OK при любых обстоятельствах.

Что хорошо. Но затем я смотрю на статью MSDN, подробно описывающую написание объекта Browser Helper, и есть его код для IObjectWithSite.SetSite, и он возвращает HRESULTS, отличный от S_OK:

  • E_INVALIDARG если pUnkSite равен NULL
  • E_INVALIDARG, если pUnkSite не поддерживает IWebBrowser2
  • E_POINTER, если webBrowser не поддерживает IConnectionPointContainer
  • результат подключения к событию в противном случае (т.е. S_OK) 
HRESULT CViewSource::SetSite(IUnknown *pUnkSite)
{
  // Retrieve and store the IWebBrowser2 pointer 
  m_spWebBrowser2 = pUnkSite; 
  if (m_spWebBrowser2 == NULL)
   return E_INVALIDARG;

  // Retrieve and store the IConnectionPointerContainer pointer 
  m_spCPC = m_spWebBrowser2;
  if (m_spCPC == NULL) 
   return E_POINTER;

  // Retrieve and store the HWND of the browser. Plus install
  // a keyboard hook for further use
  RetrieveBrowserWindow();

  // Connect to the container for receiving event notifications
  return Connect();
}

Тот факт, что код возвращает E_INVALIDARG, если pUnkSite имеет значение NULL, выглядит как ошибка, в документации конкретно сказано, что параметр может быть нулевым.

В документации не упоминаются никакие другие HRESULTS в качестве возможных возвращаемых значений - фактически говорится, что S_OK должен быть возвращен при любых обстоятельствах ?

Конечно, они не могут быть серьезными; они не могут означать все обстоятельства. Правильно? Что делать, если нехватка памяти или сбой защиты памяти из-за того, что кто-то вытащил карту памяти?

Каково правило возврата недокументированных HRESULTS из документированных стандартных объектов COM?

1 Ответ

0 голосов
/ 27 июня 2011

Когда вы занимаетесь программированием COM, вы в целом очень оборонительны. Таким образом, в качестве вызывающей стороны вы используете известные макросы FAILED или SUCCEEDED (или эквивалент в используемом языке) при вызове функций интерфейса.

Однако, если в документации указано, что результат не важен, рекомендуется не проверять результат. Так что, как звонящий, я бы сделал 

...
myObject.SetSite(whatever);
...

вместо 

...
if (FAILED(myObject.SetSite(whatever))) goto error;
...

Обратите внимание, что это довольно специфично, потому что SetSite задокументирован следующим образом.

Если я не буду внимательно читать документ (как вы это делали) и предположить, что это интерфейсный вызов «обычный возврат из hresult», я бы использовал макрос FAILED. Если вы вернете что-либо недокументированное, FAILED все равно его поймает, и я все равно буду в безопасности.

...