Zastosowanie NotImplementedException

Czy uważanie NotImplementedExceptionza kod, którego jeszcze nie napisałeś, jest uważane za złą praktykę ? Być może komentarze do zrobienia TODO będą uważane za bezpieczniejsze?

Uważam, że NotImplementedExceptionto dobra praktyka.

Rzeczywiście, jeśli zapomnisz zaimplementować metodę i użyjesz jej później w swoim projekcie (i uwierz mi, to się zdarza), możesz długo debugować, szukając tego, co poszło nie tak krok po kroku. Jeśli masz wyjątek, program zatrzyma się bezpośrednio, wyświetlając monit o wyjątek (jeśli złapiesz wyjątek, szybko go znajdziesz, sprawdzając, jaki wyjątek został złapany).

Polecam używanie komentarzy NotImplementedException połączonych z TODO, aby połączyć pomoc GUI (z zadaniami w VS) i bezpieczeństwo programu.

W przypadku wersji wydanej jest to, moim zdaniem, jeszcze ważniejsze, ponieważ w większości przypadków wolisz, aby twój program się zawiesił niż program, który najwyraźniej działa poprawnie, ale daje błędne wyniki.

To zależy od twojej ogólnej filozofii wokół błędów i obsługi błędów. Jestem typem faceta „twardego błędu”: rzucę wyjątek przy najmniejszej wskazówce, że coś może być nie tak; Zapewnię wszystko; Jeśli wystąpi błąd, jeśli czegoś tam oczekiwano, a nie ma go, lub jeśli coś tam jest i nie powinno, cały wszechświat musi się zatrzymać. Okrzyk wykrzyknika musi rozbrzmiewać złowieszczo przez głośniki.

Są inni ludzie, którzy wolą nie przejmować się błędami. A co, jeśli wyślemy go do klienta, a cały moduł raportów zaginie, ponieważ zapomnieliśmy go zakodować, a nikt w testach nie zdawał sobie z tego sprawy, ponieważ aplikacja była zbyt cicha? Lepiej nic nie rób, niż rzuć wyjątek w twarz klienta!

Powiedziałbym, że to dobry pomysł. Zazwyczaj widzę te wyjątki zgłaszane przez kod szkieletu, który jest automatycznie generowany z formularza, diagramu lub czegoś takiego. Wyjątek przypomina mi o zaimplementowaniu kodu i zapewnia, że ​​wystąpią błędy, jeśli spróbuję użyć funkcji, która została skonfigurowana, ale nigdy nie została w pełni zaimplementowana. Czasami usunę go lub zastąpię czymś, co rzadziej wstrzymuje wykonanie (np. Wypisanie ostrzeżenia na konsoli), ale okazuje się, że to działa dla mnie.

Jeśli budujesz bibliotekę, z której będą korzystać inni, ten wyjątek jest lepszy niż alternatywa, co oznacza, że ​​użytkownik twojej biblioteki wywołuje funkcję i zastanawia się, dlaczego nic się nie wydarzyło. Oczywiście nadal bardzo źle jest mieć ten wyjątek w dostarczonej bibliotece, ale lepiej niż ciche błędy, IMO.

Myślę, że to dobra praktyka. Alternatywą jest propagowanie niepoprawnej wartości lub stanu, co wpłynie zarówno na kod testowy, jak i produkcyjny.

Zawsze używam NotImplementedException- w końcu po to właśnie jest.

Jest to związane z pojęciem „szybko zawieść”: jeśli Twój kod zgłasza wyjątek, należy go złapać przed przejściem do produkcji. Jeśli trafi do produkcji, to przynajmniej klient wie, że złożenie jest nieprawidłowe .

Jeśli kod zwróci wartość bez znaczenia lub, w przypadku voidmetod, nie podejmie żadnych działań, wówczas konsumenci Twojego kodu mogą rozsądnie sądzić, że wywołanie było sensowne, gdy tak nie było. Później, gdy otrzymają poprawny kod, jego kod może się zepsuć, ponieważ zależy to od poprzedniego niepoprawnego zachowania.

Co to za projekt? Praca czy dom? W domu rób co chcesz - cokolwiek najlepiej przypomina ci, że musisz dokończyć cokolwiek, nad czym pracujesz.

W pracy zakończ pisanie.

Nie widzę sytuacji, w której sprawdzałbym kod, który może / zniszczy innych programistów, kontrolę jakości lub kompilację.

Robię zarówno ja, jak i \ todo w moim doxygene autodocowaniu, a następnie rzucam wyjątek. W ten sposób, jeśli ludzie nie będą mieli problemu z RTFM, przynajmniej będą mogli dowiedzieć się, dlaczego ich program się zawiesił, zamiast zastanawiać się, dlaczego istnieje zadeklarowana funkcja, która nie zwraca wartości logicznej.