Obsługa błędów i zwracane wartości
Pakiety VSPackage i COM używają tej samej architektury w przypadku błędów. Funkcje SetErrorInfo
i GetErrorInfo
są częścią interfejsu programowania aplikacji Win32 (API). Każdy pakiet VSPackage w zintegrowanym środowisku projektowym (IDE) może wywoływać te globalne interfejsy API Win32 w celu rejestrowania zaawansowanych informacji o błędach podczas odbierania powiadomienia o błędzie. Zestaw SDK programu Visual Studio udostępnia zestawy międzyoperacowe do zarządzania informacjami o błędach.
Metody międzyoperacyjnych
Dla wygody środowisko IDE udostępnia metodę , SetErrorInfodo użycia zamiast wywoływania interfejsów API Win32. W kodzie zarządzanym użyj polecenia SetErrorInfo. Po nadejściu błędu HRESULT
na poziomie, na którym powinien zostać wyświetlony komunikat o błędzie (często jest to obiekt implementowania IOleCommandTarget programu obsługi poleceń), środowisko IDE używa innej metody , ReportErrorInfo, aby wyświetlić odpowiednie pole komunikatu. W kodzie zarządzanym ReportErrorInfo użyj metody .
Jako implementator vsPackage obiekty COM zwykle implementują element ISupportErrorInfo
. Interfejs ISupportErrorInfo
zapewnia, że zaawansowane informacje o błędach mogą przenosić się w pionie w górę łańcucha wywołań. Obiekty, które mogą być używane w procesach lub w wątkach, muszą obsługiwać ISupportErrorInfo
, aby upewnić się, że zaawansowane informacje o błędach są prawidłowo marshalowane z powrotem do obiektu wywołującego.
Wszystkie obiekty powiązane z pakietami VSPackage i związane z rozszerzaniem środowiska IDE, w tym fabryki edytorów, edytory, hierarchie i oferowane usługi, powinny obsługiwać zaawansowane informacje o błędach. Chociaż środowisko IDE nie wymaga implementacji ISupportErrorInfo
tych obiektów VSPackage, zawsze jest zachęcane.
Środowisko IDE jest odpowiedzialne za raportowanie informacji o błędach i wyświetlanie ich użytkownikowi programu Visual Studio za każdym razem, gdy HRESULT
obiekt jest propagowany do środowiska IDE. Środowisko IDE jest również mechanizmem tworzenia ErrorInfo
obiektów.
Ogólne wskazówki
Za pomocą SetErrorInfo metod i ReportErrorInfo można również ustawiać i zgłaszać błędy wewnętrzne implementacji pakietu VSPackage. Jednak zgodnie z ogólną zasadą postępuj zgodnie z tymi wytycznymi dotyczącymi obsługi komunikatów o błędach w programie VSPackage:
Zaimplementuj
ISupportErrorInfo
obiekty COM pakietu VSPackage.Utwórz mechanizm raportowania błędów, który wywołuje metodę w obiektach implementujących IOleCommandTargetmetodę SetErrorInfo .
Pozwól, aby środowisko IDE wyświetlało użytkownikom błędy za pomocą ReportErrorInfo metody .
Informacje o błędzie w środowisku IDE
Następujące reguły wskazują, jak obsługiwać informacje o błędach w środowisku IDE programu Visual Studio:
Jako strategia defensywna gwarantująca, że nieaktualne informacje o błędzie nie są zgłaszane użytkownikom, funkcje wywołujące ReportErrorInfo metodę powinny najpierw wywołać metodę SetErrorInfo . Przekaż polecenie ,
null
aby wyczyścić buforowane komunikaty o błędach przed wywołaniem niczego, co może spowodować ustawienie nowych informacji o błędzie.Funkcje, które nie zgłaszają bezpośrednio komunikatów o błędach, mogą wywoływać metodę SetErrorInfo tylko wtedy, gdy zwracają błąd
HRESULT
. Dopuszczalne jest wyczyszczenieErrorInfo
obiektu we wpisie do funkcji lub przy zwracaniu S_OKelementu . Jedynym wyjątkiem od tej reguły jest, gdy wywołanie zwraca błądHRESULT
, z którego strona odbierający może jawnie odzyskać lub bezpiecznie zignorować.Każda strona, która jawnie ignoruje błąd
HRESULT
, musi wywołać metodę SetErrorInfo za pomocą S_OKmetody . W przeciwnym razie obiekt może zostać przypadkowo użyty,ErrorInfo
gdy inna strona generuje błąd bez podawania własnegoErrorInfo
obiektu .Wszystkie metody, które pochodzą z błędu
HRESULT
, są zachęcane do wywołania metody w SetErrorInfo celu dostarczenia zaawansowanych informacji o błędzie. Jeśli zwróconyHRESULT
błąd jest specjalnymFACILITY_ITF
błędem, metoda jest wymagana do dostarczenia odpowiedniegoErrorInfo
obiektu. Jeśli zwrócony błąd jest standardowym błędem systemowym (na przykład E_OUTOFMEMORY, , E_ABORTE_INVALIDARG, , E_UNEXPECTEDi tak dalej). Dopuszczalne jest zwrócenie kodu błędu bez jawnego wywołania SetErrorInfo metody. Jako defensywna strategia kodowania, podczas tworzenia błęduHRESULT
(w tym błędów systemowych), zawsze należy wywołać SetErrorInfo metodę , opisującErrorInfo
błąd bardziej szczegółowo lubnull
.Wszystkie funkcje, które zwracają błąd pochodzący z innego wywołania, muszą przekazać informacje odebrane z wywołania zakończonego niepowodzeniem w
HRESULT
obiekcie bez modyfikowaniaErrorInfo
obiektu.