Compartir a través de

Control de errores y valores devueltos

  • Artículo

VSPackages y COM usan la misma arquitectura para los errores. Las SetErrorInfo funciones y GetErrorInfo forman parte de la interfaz de programación de aplicaciones (API) win32. Cualquier VSPackage en el entorno de desarrollo integrado (IDE) puede llamar a estas API globales de Win32 para registrar información de error enriquecida al recibir una notificación de error. El SDK de Visual Studio proporciona ensamblados de interoperabilidad para administrar la información de error.

Métodos de interoperabilidad

Como comodidad, el IDE proporciona un método , SetErrorInfopara usar en lugar de llamar a las API de Win32. En código administrado, use SetErrorInfo. Cuando llega un error HRESULT al nivel en el que se debe mostrar el mensaje de error (suele ser el objeto que implementa un IOleCommandTarget controlador de comandos), el IDE usa otro método, ReportErrorInfo, para mostrar el cuadro de mensaje adecuado. En código administrado, use el ReportErrorInfo método .

Como implementador de VSPackage, los objetos COM normalmente implementan ISupportErrorInfo. La ISupportErrorInfo interfaz garantiza que la información enriquecida del error se pueda mover verticalmente hacia arriba de la cadena de llamadas. Los objetos que se pueden usar entre procesos o entre subprocesos deben admitirse ISupportErrorInfo para asegurarse de que la información de error enriquecida se serializa correctamente al autor de la llamada.

Todos los objetos relacionados con VSPackages y que intervienen en la extensión del IDE, incluidos generadores de editores, editores, jerarquías y servicios ofrecidos, deben admitir información de error enriquecida. Aunque el IDE no requiere estos objetos VSPackage para implementar ISupportErrorInfo, siempre se recomienda.

El IDE es responsable de notificar información de errores y mostrarla a un usuario de Visual Studio cada vez que HRESULT se propaga un elemento al IDE. El IDE también es el mecanismo para crear ErrorInfo objetos.

Directrices generales

También puede usar los SetErrorInfo métodos y ReportErrorInfo para establecer y notificar errores internos en la implementación de VSPackage. Sin embargo, como regla general, siga estas instrucciones para controlar los mensajes de error en VSPackage:

  • Implemente ISupportErrorInfo en los objetos COM de VSPackage.

  • Cree un mecanismo de informes de errores que llame al SetErrorInfo método en objetos que implementan IOleCommandTarget.

  • Permitir que el IDE muestre errores a los usuarios a través del ReportErrorInfo método .

Información de error en el IDE

Las reglas siguientes indican cómo controlar la información de error en el IDE de Visual Studio:

  • Como estrategia defensiva para garantizar que la información de error obsoleta no se notifica a los usuarios, las funciones que llaman al ReportErrorInfo método deben llamar primero al SetErrorInfo método. Pase para borrar los mensajes de error almacenados en null caché antes de llamar a cualquier elemento que pueda establecer información de error nueva.

  • Las funciones que no notifican directamente los mensajes de error solo pueden llamar al SetErrorInfo método si devuelven un error HRESULT. Se permite borrar en ErrorInfo la entrada a una función o al devolver S_OK. La única excepción a esta regla es cuando una llamada devuelve un error HRESULT desde el que el usuario receptor puede recuperar o omitir de forma segura explícita.

  • Cualquier entidad que omita explícitamente un error HRESULT debe llamar al SetErrorInfo método con S_OK. De lo contrario, el ErrorInfo objeto podría usarse accidentalmente cuando otra entidad genera un error sin proporcionar su propio ErrorInfo.

  • Se recomienda que todos los métodos que originen un error HRESULT llamen al SetErrorInfo método para proporcionar información de error enriquecida. Si el devuelto HRESULT es un error especial FACILITY_ITF , se requiere el método para proporcionar un objeto adecuado ErrorInfo . Si el error devuelto es un error del sistema estándar (por ejemplo, E_OUTOFMEMORY, E_ABORTE_INVALIDARG, E_UNEXPECTEDetc.), es aceptable devolver el código de error sin llamar explícitamente al SetErrorInfo método . Como estrategia de codificación defensiva, al originar un error (incluidos los errores HRESULT del sistema), llame siempre al SetErrorInfo método , ya sea con ErrorInfo la descripción del error con mayor detalle o null.

  • Todas las funciones que devuelven un error originado por otra llamada deben pasar la información que se recibió de la llamada con error en sin HRESULT modificar el ErrorInfo objeto .

Consulte también