Tratamento de erros e valores de retorno
Os VSPackages e COM usam a mesma arquitetura de erros. O SetErrorInfo e GetErrorInfo funções são parte da interface de programação de aplicativo (API) do Win32. Qualquer VSPackage no ambiente de desenvolvimento integrado (IDE) pode chamar essas APIs do Win32 global para registrar informações de erro rich ao receber uma notificação de erro. O SDK do Visual Studio fornece assemblies de interoperabilidade para gerenciar informações de erro.
Métodos de interoperabilidade
Como uma conveniência, o IDE fornece um método, SetErrorInfo, para usar em vez de chamar as APIs do Win32. No código gerenciado usam SetErrorInfo. Quando um erro HRESULT chegar no nível em que a mensagem de erro deve ser exibida (geralmente, esse é o objeto implementando um IOleCommandTarget manipulador de comandos), o IDE usa outro método, ReportErrorInfo, para exibir a caixa de mensagem apropriada. No código gerenciado usam o ReportErrorInfo método.
Como um implementador VSPackage, seus objetos COM normalmente implementam ISupportErrorInfo. O ISupportErrorInfo interface garante que as informações de erro rich podem mover verticalmente a cadeia de chamada. Devem oferecer suporte a objetos que podem ser usados em processos ou threads ISupportErrorInfo para garantir que as informações de erro rich corretamente são empacotadas volta para o chamador.
Todos os objetos que estão relacionadas a VSPackages e que estão envolvidas na extensão do IDE, incluindo as fábricas de editor, editores, hierarquias e ofereceu serviços, devem dar suporte a informações com erros. Enquanto o IDE não requer esses objetos VSPackage implementar ISupportErrorInfo, ele sempre é encorajado.
O IDE é responsável por relatar informações de erro e exibi-lo para um usuário de Visual Studio sempre que uma HRESULT é propagada para o IDE. O IDE também é o mecanismo para a criação de ErrorInfo objetos.
Diretrizes gerais
Você pode usar o SetErrorInfo e ReportErrorInfo métodos para definir e relatar erros que são internos também sua implementação VSPackage. No entanto, como regra geral, siga estas diretrizes para o tratamento de mensagens de erro no seu VSPackage:
Implementar ISupportErrorInfo em seus objetos COM VSPackage.
Criar um mecanismo que chama de relatório de erros do SetErrorInfo método em objetos que implementam IOleCommandTarget.
Deixar o IDE para exibir erros para usuários por meio do ReportErrorInfo método.
Informações de erro no IDE
As regras a seguir indicam como lidar com informações de erro na Visual Studio IDE:
Como uma estratégia defensiva para garantir que informações de erro obsoletos não é relatada para os usuários, funções de chamada a ReportErrorInfo método primeiro deve chamar o SetErrorInfo método. Passar no null para limpar as mensagens de erro em cache antes de chamar qualquer coisa que pode definir novas informações de erro.
Funções que reportam diretamente as mensagens de erro são permitidas apenas para chamar o SetErrorInfo método se eles estão retornando um erro HRESULT. É permitido para limpar o ErrorInfo na entrada para uma função ou ao retornar S_OK. A única exceção a essa regra é quando uma chamada retorna um erro HRESULT de que a parte destinatária pode recuperar explicitamente ou ignorar com segurança.
Todas as pessoas que claramente ignora um erro HRESULT deve chamar o SetErrorInfo método com S_OK. Caso contrário, o ErrorInfo objeto pode ser usado acidentalmente quando outra pessoa gera um erro sem fornecer suas próprias ErrorInfo.
Todos os métodos que se originam de um erro HRESULT são incentivados a chamar o SetErrorInfo método para fornecer informações com erros. Se o retornado HRESULT é um especial FACILITY_ITF erro e, em seguida, o método deve fornecer um PRI ErrorInfoobjeto. Se o erro retornado é um erro de sistema padrão (por exemplo, E_OUTOFMEMORY, E_ABORT, E_INVALIDARG, E_UNEXPECTEDe assim por diante.) é aceitável para retornar o código de erro sem chamar explicitamente o SetErrorInfo método. Como uma estratégia de codificação defensiva, quando um erro de origem HRESULT (incluindo erros de sistema), sempre chamar o SetErrorInfo método, com ErrorInfo descrevendo a falha em maiores detalhes, ou null.
Todas as funções que retornam um erro foi originado por outra chamada deve passar as informações que foram recebidos de falha do chamam o HRESULT sem modificar o ErrorInfo objeto.