2010-08-13 7 views
6

W patrząc na niektóre kodu odbitego od bibliotek WCF, widzę wzór używany do tworzenia wyjątkami:Jaka jest wartość fabryk wyjątków?

if(argument == null) 
{ 
    throw Error.ArgumentNull("argument"); 
} 

Null argumentów będących najprostszy przykład, w przypadku innych rodzajów wyjątków dostępnych w statycznej klasie błędu.

Jaka jest wartość tego wzoru fabrycznego? Dlaczego nie skorzystać z operatora new i po prostu zadzwonić do konstruktora ArgumentNullException?

Odpowiedz

2

Najważniejszym powodem, dla którego znalazłem, jest standaryzacja sposobu obsługi i definiowania wyjątków w ramach określonego zespołu (lub zespołów). Nawet firma Microsoft publikuje, że różne typy wyjątków nie są specjalnie standardowe między wyjątkami Exception, SystemException i ApplicationException. Może się zdarzyć, że potrzeby wyjątku mogą się różnić w zależności od zasad dotyczących konkretnych przypadków logicznych. Jest także przydatny do usuwania typowych zadań (takich jak logowanie) z codziennych problemów deweloperów. Deweloper musi tylko użyć odpowiedniego wyjątku w fabryce, a fabryka zajmie się resztą.

+0

Masz jakieś przykłady tego rodzaju normalizacji, do którego się odwołujesz? –

+0

@Programming Hero - Odnosiłem się do wewnętrznych standardów. Na przykład w naszym zespole programistycznym tutaj w pracy, my (potencjalni klienci) spotkaliśmy się krótko po przydzieleniu do naszego pierwszego projektu i wyjaśniliśmy podstawy tego, czego szukaliśmy: standardy nazw, rejestrowanie, obsługa wyjątków, obsługa zdarzeń, n-tier architektura, itp. Nie stworzyliśmy sami fabryki, ale w dokumentach dotyczących standardów określiliśmy, jak używać wyjątku System.Exception zamiast ApplicationException oraz standardów, w których wyjątki powinny być rejestrowane, przechwytywane, obsługiwane lub ignorowane. –

0

Fabryka może wykonać dodatkowe prace, na przykład logować wyjątek?

+1

Mogła rejestrować tylko tworzenie wyjątku. Na tym etapie nie ma śladu stosu ani żadnych naprawdę użytecznych informacji. –

+0

@Programowanie Hero: Mogło _koncepcyjnie_ używać klasy 'StackTrace' do tworzenia śladu stosu. Nie tak powinno być. –

5

Myślę, że główną przyczyną jest to, że komunikaty o wyjątkach .NET są zlokalizowane. Faktyczny tekst komunikatu musi zostać pobrany z zasobu ciągów. Lepiej umieścić ten kod w jednym miejscu, aby nikt nie zgadł nazwy zasobu ciągów.

Pomysł użycia fabryki tak, aby faktyczny typ wyjątku mógł zostać zmodyfikowany, wydaje mi się mniej przydatny. Może to spowodować złamanie wielu kodów klienta, które z jakiegoś powodu próbują przechwycić ten wyjątek. Po wysłaniu kodu, który zgłasza konkretny wyjątek, jesteś prawie z tym związany. Wybieraj mądrze :)