Jaki wyjątek do rzucania na nieprawidłowy stan obiektu?

Question

Zawsze brakowało mi wbudowanego typu wyjątku w języku C#, który wskazywałby, że obiekt jest uszkodzony. Co rzucasz w takich przypadkach?

Zwykle tęsknię za tym, gdy zdaję sobie sprawę, że metoda, która ma działać na obiekcie, zakończyłoby się niepowodzeniem, gdyby obiekt miał określony stan. W takich sytuacjach często podejrzewam, że ten stan prawdopodobnie nigdy nie zostanie osiągnięty. Ale będąc w defensywie, chciałbym rzucić wyjątek na wszelki wypadek (np. Po zmianie kodu w przyszłości).

Dla argumentów metody mamy ArgumentException, więc możemy odmówić nieprawidłowe parametry. Ale dla stanu obiektu? W Javie użyłbym IllegalStateException.

Oczywiście można argumentować, że metody, które faktycznie zmieniają stan, mogą sprawdzić poprawność stanu. I lepiej, powinniśmy, ale jeśli nie (powiedzmy w starszych klasach boga)?

Edit:

Chociaż InvalidOperationException wydaje się być najlepiej nadających się przyjętych państw Odpowiedź (a także this one) uwaga:

To jest subtelna, ale semantycznie to ma inne znaczenie niż InvalidOperationException. InvalidOperationException oznacza problem z "protokołem" obiektu, którego osoba wywołująca musi przestrzegać (np. Nie została zainicjowana, zamknięta, ...). W moim przypadku dzwoniący nie zrobił nic złego, jest to obiekt, który jest zepsuty. Chciałbym przetransportować dokładnie tę wiadomość.

Przykład:

switch(this._someType) { 
    case SomeType.A: doSomething(); break; 
    case SomeType.B: doSomethingElse(); break; 
    /*...*/ 
    default: 
    // Unexpected type! Someone introduced a new type and didn't update this. 
    throw new IllegalStateException("Unknown type "+this._someType); 
} 

Answer 1

Należy wyrzucić InvalidOperationException aby wskazać, że obiekt ma nieprawidłowy stan.

Z dokumentacji MSDN (połączone powyżej):

wyjątkiem tego, że jest generowany, gdy połączenie jest nieprawidłowe sposób o stan obiektu.

Answer 2

Najbliższy analog można ustalić jako od Net 2,0 [coś lepiej może być dodane, ponieważ] byłoby ObjectDisposedException, co oznacza, że ​​przedmiot został umieszczony na stałe, nieprawidłowy stan. Taki wyjątek można uznać za "nieoczekiwany", ale to dobrze, ponieważ warunek, który wskazuje, byłby również nieoczekiwany. Ponadto, jeśli metoda na obiekcie wykryje, że jego stan jest nieprawidłowy, powinien po przechwyceniu jak największej ilości informacji o stanie obiektu, które mogą być pomocne przy rozwiązywaniu problemów, celowo umieścić obiekt w stanie trwale nieważnym, tak aby wszystkie przyszłe operacje na nim (poza prośbami o wyodrębnienie informacji, które zostały przechwycone w celu rozwiązywania problemów) rzuci wyjątek.

Z powodu silnego powiązania między IDisposable i ObjectDisposedException, może być lepiej zdefiniować nowy typ wyjątku, który może, ale nie musi dziedziczyć po ObjectDisposedException. Prawdopodobnie, ObjectDisposedException powinno być wyprowadzone z ObjectInvalidatedException, które powinno również mieć CorruptObjectDiscoveredException i CorruptObjectInvalidatedException [poprzednia jest wyrzucana przez pierwszą metodę, która znajduje korupcję, a druga przez kolejne wywołania metody na tym samym obiekcie], ale ja nie jestem na pewno to ma znaczenie.

Najważniejsze jest zapewnienie, że kod, który ma powody przypuszczać, że obiekt może znajdować się w stanie uszkodzonym, wyraźnie unieważnia ten obiekt. Niektórzy sugerują, że metody, które odkrywają nieoczekiwane problemy, powinny próbować obalić cały system. Zdecydowanie nie zgadzam się z tą filozofią. Jeśli metoda umieszcza obiekt w tym, co ma być stanem tymczasowo uszkodzonym, a następnie kończy się przez wyjątek, zanim stan obiektu może zostać naprawiony, powinien całkowicie unieważnić obiekt, zamiast pozostawiać go uszkodzonym. Jeśli po rozwinięciu stosu system nie będzie mógł działać bez teraz unieważnionego obiektu, nastąpi jego zawieszenie w krótkim czasie (lepsza alternatywa niż funkcjonowanie z uszkodzonym stanem). Jeśli jednak proces rozwijania stosu powoduje porzucenie uszkodzonego obiektu (np. Ktoś próbował załadować dokument z pliku niewłaściwego typu, powodując wyjątek w metodzie nazwanej przez LoadDocument), fakt, że obecnie obiekt porzucony jest uszkodzony może być użyteczną informacją dla zrozumienia przyczyny wyjątku, ale może nie mieć żadnych negatywnych konsekwencji dla ogólnego stanu systemu.