Software design, wyjątki vs kody wyjścia

Question

Mam problem architektoniczny. Jest sobie funkcja, która naprawia nagłówek licencyjny w pliku źródłowym. Naprawa może wymagać:

• dodania nagłówka bo tam go nie było
• poprawienia nagłówka bo był, ale był zły

lub może polecieć wyjątek, bo plik nie istnieje
Potrzebuje po wywołaniu funkcji dowiedzieć się co się stało.
Obecnie taka informacja jest przekazywana na zewnątrz w postaci typu rzuconego wyjątku. Każdy przypadek to inny wyjątek. Tak wiem, ale nie ja to pisałem.
Pytanie brzmi: jak to naprawić, żeby nie używać wyjątków do sterowania poprawnym przebiegiem, programu, ale zachować dotychczasową funkcjonalność.

Na pierwszy rzut oka problem rozwiązałby enum HeaderFixReturnStatus, ale koncepcja return code'ów trochę kojarzy mi się z prehistorią, a nie czystym kodem.

Jak to poprawić? Return code'y czy może coś innego?

BTW - szkoda, że nie ma kategorii do ogólnych pytań o architekturę oprogramowania.

Comments

Czy możesz ingerować w kod, czy musisz jakoś opakować to, co już masz bez modyfikacji kodu?

---

Mogę modyfikować do woli.

---

Można rozważyć opakowanie takich operacji w klasę. Każdy jej obiekt, to jeden plik źródłowy przekazywany jako parametr do metody __init__.  Obiekt wywoływałby pomocniczą metodę, która parsowałaby dany plik i ustawiała jego status (w przypadku braku pliku źródłowego zrzucany byłby wyjątek). Na podstawie statusu wykonywana byłaby naprawa pliku lub jej brak. Chodzi o osiągnięcie takiego czegoś:

>>> foo = SourceFile("foo.cpp")
>>> foo.fix_status
0
>>> bar = SourceFile("bar.cpp")
>>> bar.fix_status
1

W dalszej kolejności można by pomyśleć o odseparowaniu konkretnego nagłówka licencyjnego od klasy SourceFile, tak aby można było łatwo podmieniać licencje. W takim przypadku również pojawia się możliwość odseparowania parsera.

W każdym razie, nawet niedoskonały powyższy kod wydaje się ciut sensowniejszy niż rzucanie wyjątkami. Z drugiej strony ciężko powiedzieć jak bardzo "udana" jest reszta kodu i jaki będzie koszt takich poprawek.

---

Interfejs jest spoko o ile po stworzeniu sourcefile jest jeszcze jakieś zawołanie metody fix_header, bo wywołanie tego po cichu w inicie trochę zaciemnia co ta klasa ma zrobić.

Answer 1

To mocno zależy od kontekstu działania aplikacji i stylu w jakim jest napisana. IMHO lepiej się dostosować do sposobu myślenia w kodzie niż na siłę robić "rewolucję refaktoryzacji" (oczywiście poza przypadkami patolgicznymi). Rzucanie wyjątkami jako logika głównego przepływu sterowania, to taka patologia.

Na pierwszy rzut oka, brak pliku to sytuacja wyjątkowa i IMHO powinna owocować wyjątkiem. Przypadki dodania nagłówka lub poprawienia błędnego ale już istniejącego, to informacja o powodzie wykonania operacji. Sama operacja się wykonała więc... stan zastany przed wykonaniem operacji, można ew. logować. Jeśli chcesz mieć do niego dostęp w logice, cóż... zwróć rezultatem :)

Jak pisałem wyżej, tak to widzę przy niepełnych danych.

Answer 2

Tak wiem, ale nie ja to pisałem. 
Pytanie brzmi: jak to naprawić, żeby nie używać wyjątków do sterowania poprawnym przebiegiem, programu

Mówisz o Pythonie, tak? (zgaduję z kategorii)

Tam używanie wyjątków do "normalnego przebiegu" jest dość powszechnym, niemalże idiomatycznym podejściem. Na przykład

try:
    with open(...) as f:
        ...
except IOError:
    ...

Ma parę zalet nad

if exists(...):
    with open(...) as f:
        ...
else:
    ...

, gdyż obsługuje więcej możliwych sytuacji i nie ma (mikroskopijnego) ryzyka że inny proces akurat usunie plik między linią exists() a linią open() ;)

Nie mówię że tak jest w Twojej konkretnej sytuacji, ale chciałem tylko zaznaczyć że w Pythonie podejście do wyjątków jest odrobinę inne niż w takim C++ie. No i zależy od poziomu abstrakcji tego API - funkcja edytująca konkretny plik może rzucić wyjątkiem że plik nie istnieje, ale już np funkcja wyższego poziomu działająca na całym projekcie być może by ten wyjątek złapała i zwróciła coś innego.

Comments

Tam używanie wyjątków do "normalnego przebiegu" jest dość powszechnym, niemalże idiomatycznym podejściem

Jeszcze lepszy przykład to tworzenie iteratora który rzuca StopIteration.

Brak pliku to sytuacja wyjwtkowa, która uniemożliwia kontynuowanie programu, więc wyjątek jest jak najbardziej uzasadniony.

W moim przypadku header jest naprawiony, więc wszystko poszło zgodnie z planem i można kontynuować pogram, dlatego taki wyjątek to patologia i chciałem go wyeliminować.