Pytanie:

Co uważa się za „najlepszą praktykę” -i dlaczego - obsługi błędów w konstruktorze ?.

„Najlepsza praktyka” może być cytatem z Schwartza lub 50% modułów CPAN z niego korzysta, itd ...; ale cieszę się z dobrze uzasadnionej opinii od każdego, nawet jeśli wyjaśnia, dlaczego wspólna najlepsza praktyka nie jest najlepszym podejściem.

Jeśli chodzi o mój własny pogląd na ten temat (informowany przez wiele lat o rozwoju oprogramowania w Perlu), widziałem trzy główne podejścia do obsługi błędów w module perla (moim zdaniem wymienione od najlepszego do najgorszego):

Skonstruuj obiekt, ustaw nieprawidłową flagę (zwykle ”is_valid„Metoda” często połączona z ustawieniem komunikatu o błędzie za pomocą obsługi błędów w klasie.

Plusy:

Umożliwia standardową (w porównaniu do innych wywołań metod) obsługę błędów, ponieważ pozwala na użycie$obj->errors() wpisz wywołania po złym konstruktorze, tak jak po każdym innym wywołaniu metody.

Umożliwia przekazanie dodatkowych informacji (np.> 1 błąd, ostrzeżenia itp.)

Pozwala na lekką funkcję „redo” / „fixme”, Innymi słowy, jeśli obiekt, który jest skonstruowany, jest bardzo ciężki, z wieloma złożonymi atrybutami, które są w 100% zawsze OK, a jedynym powodem, dla którego jest on niepoprawny, jest to, że ktoś wprowadził niepoprawna data, możesz po prostu zrobić „$obj->setDate()„zamiast narzutu ponownego ponownego wykonania całego konstruktora. Ten wzór nie zawsze jest potrzebny, ale może być niezwykle użyteczny w odpowiednim projekcie.

Cons: Brak tego, o czym wiem.

Powrót "undef„

Cons: Nie można osiągnąć żadnego z zalet pierwszego rozwiązania (komunikaty o błędach na obiekt poza zmiennymi globalnymi i lekkie „fixme” dla ciężkich obiektów).

Umrzyj wewnątrz konstruktora. Poza kilkoma bardzo wąskimi przypadkami osobiście uważam to za okropny wybór ze zbyt wielu powodów, aby wymienić je na marginesie tego pytania.

AKTUALIZACJA: Żeby było jasne, uważam rozwiązanie (poza tym bardzo godne i świetnego projektu) o bardzo prostym konstruktorze, który w ogóle nie może zawieść i metodę ciężkiego inicjalizatora, w której sprawdzanie błędów odbywa się jako podzbiór albo przypadek # 1 (jeśli inicjator ustawia flagi błędów) lub przypadek # 3 (jeśli inicjator umiera) dla celów tego pytania. Oczywiście, wybierając taki projekt, automatycznie odrzucasz opcję # 2.