¿Qué significa "TILT" en un comentario?

Estoy leyendo Clean Code de Robert C. Martin, y la frase TILTaparece inexplicablemente en algunos ejemplos de código. Ejemplo (está en Java, por cierto):

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

Por el contexto, supongo que TILTdesigna un estado que es inalcanzable y solo se incluye para satisfacer al compilador (por ejemplo, en el código anterior, TILTaparece en el ErrorCode.OKcaso porque no debería haber un mensaje de error si el estado es OK), pero No estoy seguro.

¿Alguien sabe lo que TILTsignifica / significa?

Las máquinas físicas de pinball tienen sensores que detectan cuando algo en el exterior está tratando de ejercer demasiada influencia en el camino de la pelota empujando o inclinando la máquina. (Digo demasiado aquí porque el pinball tiene una larga tradición de una cierta cantidad de movimiento aceptable, especialmente cuando la pelota se cuelga de algo). Cuando la máquina entra en el estado inclinado, cualquier cosa que pueda sumar más puntos al jugador es deshabilitado hasta que la pelota se caiga del fondo de la mesa. Esto suele ir acompañado de una luz de "inclinación" en el juego y, a veces, un timbre de advertencia. Piense en ello como el equivalente de pinball de plantear una excepción.

La metáfora de Martin es tensa porque ErrorCode.OKes, presumiblemente, una validez statusy no algo que intenta forzar a la función a hacer algo que no debería. En otras palabras, esa entrada no está intentando que la función devuelva el mensaje de error para un argumento faltante.

El resto de esto no responde a su pregunta, pero puede darle razones para leer el resto del libro con ojo crítico. No tengo acceso al libro para ver si el texto que rodea ese ejemplo hace un gesto con la mano, pero si no, el método hace cosas que no están a la altura del título:

Primero es que no trata la entrada o estado presumiblemente inválido como una condición excepcional y se queja de ello. Si la documentación del método dice que solo debe llamarse cuando el objeto statusestá en estado de error, es claramente un problema lógico en el código de llamada que debe corregirse.

En segundo lugar, devuelve una cadena que es tan válida como cualquiera de las otras pero que efectivamente sirve como una constante mágica. Una persona que llama y quiere saber si invocar el método fue un error tendrá que verificar el contenido del valor de retorno o pasarlo alegremente al humano que lo lee para descifrarlo (por ejemplo, Operation result:sin información adicional).

Un tercero opcional sería que si el compilador espera una cobertura completa de los valores enumerados, usar defaultpara capturar los casos no cubiertos es mucho más legible que tener que enumerarlos individualmente o en grupo. (El lado de filp es que podría ser mejor dejar que el compilador se queje para que agregar un segundo estado sin errores obligaría al programador a declarar explícitamente cómo se debe manejar).