Ahora mismo me veo en una situación en la que creo que puedo introducir al proyecto en el que estoy un manejo de errores y control de flujo un poquillo más limpio que devolver null y pasar por referencia strings errorMessage (xd). Para poneros en contexto, la aplicación es un monolito .net (C#) a capas (MVC) que a efectos prácticos se limita a exponer una variedad de APIs de muchos colores y sabores distintos.
Mi idea era poder representar de forma genérica el estado de una petición http o un flujo interno de la aplicación, de forma que quede clara la dicotomía entre consumo externo/interno y teniendo en mente que puede darse la situación de que un estado de éxito pueda ser parcial y acarrear mensajes de error, que no es algo muy común pero viendo el percal me veo que van a depender de muchos "servicios externos". Siempre desde la perspectiva de usarlo en desarrollos nuevos o modificaciones que cambien de forma drástica la interfaz que se expone al exterior.
El caso es que no me veo cómodo con la idea y vengo a que me tiréis unos machetes a ver.
En un principio pensé en tener dos clases para tipificar los flujos, un Result
para "operaciones internas" y un Response
con el que exponer el resultado "final". En código la clase Result sería algo así:
Utilizo un booleano Success
para ahorrarme comparativas con valores vacíos; a través del estático Result<T>.OK(T value)
se construye un Result con Success positivo (porque default(T)
/null
pueden ser estados finales de éxito). La instanciación la hago a través de métodos públicos estáticos para tener margen para poder dejar el objeto en un estado "predefinido" de éxito o fracaso; no quiero que el resultado no sea algo final en ningún momento.
La clase Response
a grandes rasgos es lo mismo, sólo que incluye una lista de tipos Error, también de sólo lectura. El overload de estáticos es por comodidad de quien lo vaya a usar más que nada. Pego aquí el código por completitud:
Y este sería el de la clase Error:
Y esto serían unos ejemplos tontos de uso:
¿Opiniones?
- follow-up: mañana tengo pensado hablar sobre cómo poder expresar estados de error que consumir de forma programática a ver si llegamos a un consenso. Me gustaría representarlo con integers pero no sé si es algo que castrará a la gente en un futuro o será suficientemente expresivo. Pensé en identificadores tirando de dos-tres siglas+numerito rollo "MV08", pero tampoco me acaba de gustar.