O que significa "TILT" em um comentário?

Estou lendo o Código Limpo, de Robert C. Martin, e a frase TILTinexplicavelmente aparece em alguns exemplos de código. Exemplo (a propósito, é em Java):

    ...
    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";
        ...
    }
    ...

No contexto, suponho que TILTdesigne um estado inacessível e incluído apenas para satisfazer o compilador (por exemplo, no código acima, TILTaparece no ErrorCode.OKcaso porque não deve haver uma mensagem de erro se o estado estiver OK), mas Não tenho certeza.

Alguém sabe o que TILTsignifica / significa?

Máquinas físicas de pinball possuem sensores que detectam quando algo externo está tentando exercer muita influência no caminho da bola, cutucando ou inclinando a máquina. (Digo muito aqui porque o pinball tem uma longa tradição de uma certa quantidade de movimento ser aceitável, especialmente quando a bola fica pendurada em alguma coisa.) Quando a máquina entra no estado inclinado, qualquer coisa que possa marcar mais pontos para o jogador é desativado até que a bola caia do fundo da mesa. Isso geralmente é acompanhado por uma luz "Tilt" no jogo e às vezes uma campainha de aviso. Pense nisso como o equivalente ao pinball de criar uma exceção.

A metáfora de Martin é tensa porque ErrorCode.OKé, presumivelmente, um válido statuse não algo que tenta forçar a função a fazer algo que não deveria. Em outras palavras, essa entrada não está tentando fazer com que a função retorne a mensagem de erro para um argumento ausente.

O restante disso não responde à sua pergunta, mas pode ser uma razão para você ler o restante do livro com um olhar crítico. Não tenho acesso ao livro para ver se o texto em torno desse exemplo faz algum sinal com a mão, mas, se não, o método faz coisas que não correspondem ao título:

Primeiro, ele não trata a entrada ou o estado presumivelmente inválido como uma condição excepcional e se queixa. Se a documentação do método diz que ele só deve ser chamado quando o objeto statusestá em um estado de erro, é claramente um problema lógico no código de chamada que precisa ser corrigido.

Segundo, ele retorna uma string que é tão válida quanto qualquer outra, mas serve efetivamente como uma constante mágica. Um chamador que deseja saber se invocar o método foi um erro terá que verificar o conteúdo do valor retornado ou repassá-lo alegremente para o ser humano que o lê para decifrar (por exemplo, Operation result:sem informações adicionais).

Um terceiro opcional seria que, se o compilador espera uma cobertura total dos valores enumerados, usar defaultpara capturar os casos não cobertos é muito mais legível do que precisar enumerá-los individualmente ou em um grupo. (O lado do filp é que talvez seja melhor deixar o compilador reclamar para que a adição de um segundo status sem erro force o programador a declarar explicitamente como ele deve ser tratado.)