Zastosowanie NotImplementedException

15

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?

— Tom Squires
źródło

6

Jaki byłby minus korzystania z takich wyjątków?

— SRKX

@SRKX Istnieje ryzyko, że wyjątki dostaną się do kodu produkcyjnego i spowodują, że cały blok kodu nie będzie działał. (jeszcze mi się nie przydarzyło, ale wszyscy mamy wolne) Osobiście korzystam z nich, martwiłem się, że mogłem przeoczyć niektóre wady.

— Tom Squires,

Co dziwne, żaden z tagów nie określa, który język jest używany. Nie dotyczy to każdego wspólnego języka, ponieważ C nie ma żadnych wyjątków. Tutaj jest miejsce na tag języka.

— David Thornley,

1

@DavidThornley, pytanie było pierwotnie oznaczone jako C #, więc przeczytałem tag.

— svick

@svick: Myślałem, że to prawdopodobnie C #. Dziękujemy za dodanie tagu.

— David Thornley,

34

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.

— SRKX
źródło

6

Jeśli używasz Resharper, pokazuje NotImplementedExceptions w taki sam sposób, jak komentarze do zrobienia TODO. Myślę, że to fajna funkcja.

— svick

1

Wrzuć trochę dobrej praktyki TDD i masz zwycięzcę

— LRE

7

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!

— Mike Nakis
źródło

To tak, jakbyś chciał mieć inne zachowanie w Debugowaniu i Wydawaniu, a twierdzenie nie zawsze je wycina. Wierzę, że kontrakty z kodem .Net można wyłączyć w wersji.

— Job

1

Najczęściej używam asercji, które również są wyłączone w wydaniu. Mam własną funkcję asercji, która uderza w punkt przerwania podczas debugowania, zgłasza wyjątek podczas testowania lub nawet nie kompiluje się po wydaniu.

— Mike Nakis

3

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.

— FrustratedWithFormsDesigner
źródło

1

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.

— Larry OBrien
źródło

1

Poczekaj .... masz na myśli, gdzie pracujesz, kod, który rzuca NotImpl, doprowadziłby aż do kontroli jakości? Nawet do produkcji?

— Steven Evers

3

Nie, wręcz przeciwnie: NotImpl to niezły, ogromny stan czerwonej flagi / błędu. Ale TODO nie mają wartości semantycznej i mogą przejść do testowania lub produkcji, po cichu psując rzeczy. (Mógłbym sobie wyobrazić politykę eliminowania TODO z produkcji, ale nie mamy takiej zasady.)

— Larry OBrien

1

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.

— phoog
źródło

0

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ę.

— Steven Evers
źródło

Cóż, staram się przestrzegać dobrych praktyk także w domu.

— Tom Squires,

0

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.

— awiebe
źródło