Udostępnij za pośrednictwem


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 ISupportErrorInfotych 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 wyczyszczenie ErrorInfo obiektu we wpisie do funkcji lub przy zwracaniu S_OKelementu . Jedynym wyjątkiem od tej reguły jest, gdy wywołanie zwraca błąd HRESULT , 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łasnego ErrorInfoobiektu .

  • 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ócony HRESULT błąd jest specjalnym FACILITY_ITF błędem, metoda jest wymagana do dostarczenia odpowiedniego ErrorInfo 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łędu HRESULT (w tym błędów systemowych), zawsze należy wywołać SetErrorInfo metodę , opisując ErrorInfo błąd bardziej szczegółowo lub null.

  • 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 modyfikowania ErrorInfo obiektu.

Zobacz też