Olamagato: Pomysł naprawdę interesujący. Tych obliczeń nie jest dużo, ale stworzenie dodatkowej klasy wydaje mi się całkiem sensowne. Prawdopodobnie póki co zastosuje zaproponowany przez Ciebie model, później może sprawdzanie powierzę metodzie statycznej(choć narzut związany z dodatkowymi obiektami pewnie będzie na tyle nieznaczący, że nic nie trzeba będzie zmieniać).
Zjarek napisał(a)
Ja trochę inaczej zawsze rozumiałem wyjątki. Kontrolowanie normalnej pracy programu za pomocą wyjątków jest złe z wielu powodów. Jeżeli np. wyrzucasz wyjątek związany z błędnymi parametrami wpisanymi od użytkownika, to łap go w funkcji która pobiera dane (i np. pozwól użytkownikowi wpisać dane jeszcze raz). Z kolei jak np. zawiódł operator new z powodu braku pamięci, to możesz nawet ten wyjątek zignorować (i pozwolić się programowi wykrzaczyć), ponieważ świadczy to o błędzie w programie. Ogólnie mówiąc łap wyjątki tam, gdzie jest to najsensowniejsze oraz stosuj je gdy zachodzi przewidywalny błąd (wspomniane złe wprowadzone dane, problemy z siecią, ogólnie tylko rzeczy poza właściwym programem). Przy debugowaniu możesz np. użyć asercji, dodatkowo stanowczo odradzam łapanie wyjątków metodą pokemonową(catch(...)).
Problem polega na tym, że dane pochodzą z kilku źródeł(plik, GUI, baza danych, sieć). O ile w przypadku GUI mogę polegać na ich poprawności(nie pozwolę użytkownikowi przeciągnąć elementu poza planszę), to w przypadku pliku/bazy danych/sieci byłby to zbytni optymizm. Jednocześnie błąd nie powinien wykrzaczać programu.
Z assertów korzystam od lat(odkąd zrozumiałem, że większości błędów nie przewidzę ;) ), Qt ma wygodne makra oferujące assert na sterydach(Q_ASSERT_X).
Dziękuję wszystkim, prawdopodobnie zastosuję się do pomysłu Olamagato.