¿Dónde es apropiado hacer la validación de entrada en Erlang?

7

Estoy escribiendo un módulo que ejecuta una máquina de estado finito * basada en el contenido de una matriz de registros que se pasaron en la inicialización. Cada registro describe un estado e incluye instrucciones sobre cómo actuar en las entradas (es decir, cuando en el estado S1 , la entrada I activa una transición al estado S2 ). Para que el FSM funcione correctamente, es necesario que existan los estados de transición a.

Mi dilema es dónde validar esas transiciones.

El programador defensivo en mí dice que lo haga una vez tan pronto como sea posible, como cuando se inicializa el FSM. Esto significa que puedo generar un error cuando me entregan por primera vez datos falsos y evitar devolver un proceso que puede fallar más tarde como resultado. El resto de la implementación no tendrá que estar tan a la defensiva porque se sabe que la tabla es buena y que cualquier error que Erlang decida plantear será un resultado de la implementación en lugar de que se le haya dado información incorrecta. También facilitará la depuración para aquellos que usan el módulo, ya que obtendrán un badarg o alguna otra cosa inmediatamente en lugar de tener que revisar mis fuentes más tarde para descubrir que fue su error y no el mío.

La filosofía de Erlang parece ser que las cosas deben dejarse correr el mayor tiempo posible, fallando solo cuando tienen que hacerlo y dejando que un supervisor se encargue de recoger las piezas. Por un lado, esto tiene sentido porque un FSM dado podría ejecutarse para siempre sin encontrar las entradas que tomaría para una mala transición. Por otro lado, si se retrasa, la responsabilidad de las personas que llaman es escribir pruebas repetitivas para algo que es fácil de implementar una vez.

Sé que la mayoría de las reglas en este negocio no son duras y rápidas, pero ¿es un enfoque más "Erlangy" que el otro? ¿Aparecería fuera de lugar una implementación fallida si se lanzara para que otros la usen?

* Soy consciente del comportamiento gen_fsm y de que lo que estoy haciendo tiene algunas deficiencias comparativas. Este es un ejercicio de aprendizaje para algunas otras cosas, y un FSM es algo que las incorpora.

    
pregunta Blrfl 18.05.2013 - 20:20

2 respuestas

1

La razón por la que parece menos "Erlangy" hacer una comprobación de tipos onerosa es porque el lenguaje se escribe dinámicamente.

Si realmente necesita asegurarse de que se usen datos de un tipo determinado, puede usar las funciones is_TYPE / 1 para verificar su entrada como expresiones de guarda. Debes hacer esto tan pronto como puedas.

enlace

    
respondido por el T.T 23.07.2013 - 17:46
0

Dictamen de Joe. Falla rápido, falla ruidosamente, falla educadamente.

Sí, comprueba tus datos. Revisa cada declaración que puedas. Así que coincide con cada llamada que puedas. Si espera una respuesta correcta de foo, escriba:

 ok = foo()

en lugar de:

foo()

Use guardas para verificar cuando pueda.

En realidad, es posible escribir código deficiente en cualquier idioma.

    
respondido por el tony wallace 02.04.2016 - 07:26

Lea otras preguntas en las etiquetas