Co oznacza „TILT” w komentarzu?

Czytam Clean Code autorstwa Roberta C. Martina, a wyrażenie w TILTniewytłumaczalny sposób pojawia się w niektórych przykładach kodu. Przykład (nawiasem mówiąc, jest w Javie):

    ...
    public String errorMessage() {
      switch (status) {
        case ErrorCode.OK:
          // TILT - Should not get here.
          return "";
        case ErrorCode.UNEXPECTED_ARGUMENT:
          return "Unexpected argument";
        case ErrorCode.MISSING_ARGUMENT:
          return "Missing argument";
        ...
    }
    ...

Z kontekstu zgaduję, że TILToznacza stan, który jest nieosiągalny i został uwzględniony tylko w celu spełnienia wymagań kompilatora (na przykład w powyższym kodzie TILTpojawia się w ErrorCode.OKprzypadku, ponieważ nie powinien być wyświetlany komunikat o błędzie, jeśli jest to stan OK), ale Nie jestem pewny.

Czy ktoś wie, co TILToznacza / oznacza?

Fizyczne automaty do gry w pinball mają czujniki, które wykrywają, kiedy coś na zewnątrz próbuje wywrzeć zbyt duży wpływ na ścieżkę piłki, trącając lub przechylając maszynę. (Mówię tu za dużo , ponieważ pinball ma długą tradycję, że pewna ilość ruchu jest akceptowalna, szczególnie gdy piłka się zawiesi.) Gdy maszyna przechodzi w stan przechylony, wszystko, co mogłoby zdobyć dla gracza więcej punktów, to wyłączone, dopóki piłka nie spadnie z dołu stołu. Zwykle towarzyszy temu lampka „Tilt” w grze, a czasem brzęczyk ostrzegawczy. Pomyśl o tym jak o pinballowym odpowiedniku zgłoszenia wyjątku.

Metafora Martina jest napięta, ponieważ ErrorCode.OKjest prawdopodobnie poprawna, statusa nie coś, co próbuje zmusić funkcję do zrobienia czegoś, czego nie powinna. Innymi słowy, to wejście nie próbuje uzyskać funkcji zwracającej komunikat o błędzie dla brakującego argumentu.

Reszta nie odpowiada na twoje pytanie, ale może dać ci powód do przeczytania reszty książki krytycznym okiem. Nie mam dostępu do książki, aby sprawdzić, czy tekst otaczający ten przykład wymachuje ręką, ale jeśli nie, metoda wykonuje czynności niezgodne z tytułem:

Po pierwsze, nie traktuje przypuszczalnie nieprawidłowych danych wejściowych lub stanu jako wyjątkowego warunku i narzeka na to. Jeśli z dokumentacji metody wynika, że ​​należy ją wywoływać tylko wtedy, gdy obiekt znajduje statussię w stanie błędu, jest to oczywiście problem logiczny w kodzie wywołującym, który należy poprawić.

Po drugie, zwraca ciąg, który jest tak samo ważny jak każdy z pozostałych, ale skutecznie służy jako magiczna stała. Osoba dzwoniąca, która chce wiedzieć, czy wywołanie metody było pomyłką, będzie musiała sprawdzić zawartość zwracanej wartości lub beztrosko przekazać ją czytającemu ją człowiekowi w celu odszyfrowania (np. Operation result:Bez dodatkowych informacji).

Opcjonalna trzecia opcja polegałaby na tym, że jeśli kompilator oczekuje pełnego pokrycia wyliczonych wartości, użycie defaultdo wychwycenia nieobjętych przypadków jest o wiele bardziej czytelne niż konieczność wyliczenia ich pojedynczo lub w grupie. (Strona filp polega na tym, że lepiej byłoby pozwolić kompilatorowi narzekać, aby dodanie drugiego, bezbłędnego statusu zmusiłoby programistę do jawnego zadeklarowania, jak należy go obsługiwać).