Cómo reemplazar la excepción de # import provocar mecanismo en C++

IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.

175784
Este artículo se ha archivado. Se ofrece "tal cual" y no se volverá a actualizar.
Nota Microsoft Visual C++ .NET 2002 y Visual C++ .NET 2003 admiten el modelo de código administrado suministrada por Microsoft .NET Framework y el modelo de código nativo no administrado de Microsoft Windows. La información de este artículo sólo se aplica al código no administrado de Visual C++.Microsoft Visual C++ 2005 admite el modelo de código administrado suministrada por Microsoft .NET Framework y el modelo de código nativo no administrado de Microsoft Windows.
Resumen
Utilizar # import para crear la aplicación cliente presenta el control de excepciones a través de la clase de excepción _com_error a un contenedor para un método del objeto encuentra un error HRESULT. Puede que tenga razones válidas para reemplazar este mecanismo con su propia implementación.
Más información
Hay dos formas de utilizar # import y que no generan excepciones de errores HRESULTS. La primera es utilizar la cláusula raw_interfaces_only con la instrucción # import. Sin embargo, esto niega algunas de las ventajas de las clases contenedoras que ofrece de # import.

La segunda técnica es proporcionar su propia implementación para _com_raise_error, que tiene la implementación predeterminada y el prototipo siguiente:
void __stdcall _com_raise_error(HRESULT hr, IErrorInfo* perrinfo = 0)   throw(_com_error);   void __stdcall   _com_raise_error(HRESULT hr, IErrorInfo* perrinfo ) throw(_com_error)   {       throw _com_error(hr, perrinfo);   } 				
esta función se declara pero no implementada en el archivo COMDEF.H. Si proporciona su propia implementación en un .obj, el vinculador utiliza en oposición a poner de COMSUPP.LIB. _com_raise_error existe en su propio objeto de COMSUPP.LIB sólo para que se puede reemplazar fácilmente por el código.

A continuación es un ejemplo de implementación de función de generación de excepción de # import:
Nota: Actualmente nuestro compilador omite una especificación de excepción de función y genera la advertencia:
Advertencia C4290: C++ especificación de excepción pasa por alto.
Según a C++ notas del producto si cualquier declaración de una función tiene una especificación excepción, todas las declaraciones, incluida la definición de esa función deben tener una especificación de excepción con el mismo conjunto de identificadores de tipo.
void __stdcall   _com_raise_error(HRESULT hr, IErrorInfo* perrinfo ) throw(_com_error)       {           //this message box is for demonstration purpose only          AfxMessageBox( "_com_raise_error (HRESULT, IErrorInfo*)" );           //your own error handling code or just an abort       }#import "C:\Program Files\Common Files\System\ado\msado15.dll" no_namespace rename("EOF", "adoEOF" )       _bstr_t     bstrEmpty(L"");       _ConnectionPtr  Conn1 = NULL;       Conn1.CreateInstance( __uuidof( Connection ) );       Conn1->Open( bstrEmpty, bstrEmpty, bstrEmpty,0 ); 					
Este código intenta abrir un objeto de conexión ADO sin proporcionar ninguna información de conexión válida. Reemplazando _com_raise_error impide que el _com_error se produzcan.

Sin embargo, sólo porque se ha reemplazado esta función, todavía tiene que interceptar las excepciones. Observe el fragmento de código siguiente.
#import "C:\Program Files\Common Files\System\ado\msado15.dll" no_namespace rename("EOF", "adoEOF" )    _ConnectionPtr  Conn1 = NULL;    // Conn1.CreateInstance( __uuidof( Connection ) );    Conn1->Open( bstrEmpty, bstrEmpty, bstrEmpty ,0); 				
en este caso, Conn1 no es un objeto válido y el puntero de interfaz a este objeto inexistente es NULL, lo que _com_raise_erro que se llama. Sin embargo, sobrecargado-> operador método devolverá una interfaz nula, en el que el compilador, a continuación, intenta llamar al método Open(), lo que produce una excepción de Win32. Pruebas Conn1 para NULL antes de llamar a Open() impediría que esta excepción.

Warning: This article has been translated automatically

Propiedades

Id. de artículo: 175784 - Última revisión: 03/01/2014 12:59:20 - Revisión: 5.0

  • Microsoft Visual C++ 2005 Express Edition
  • Microsoft Visual C++ .NET 2003 Standard
  • Microsoft Visual C++ .NET 2002 Standard
  • Microsoft Visual C++ 6.0 Enterprise
  • Microsoft Visual C++ 6.0 Professional
  • Microsoft Visual C++, 32-bit Learning Edition 6.0
  • Microsoft Visual C++ 5.0 Enterprise Edition
  • Microsoft Visual C++ 5.0 Professional
  • kbnosurvey kbarchive kbmt kbhowto kbdatabase kbinfo KB175784 KbMtes
Comentarios