Introducir result types en un proyecto vivo

Wei-Yu #1 Feb '20

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í:

spoiler

public class Result<T>
{

    readonly bool _success;
    readonly T _value;
    readonly string _error;

    Result(T value, string error, bool success)
    {
        _value = value;
        _error = error;
        _success = success;
    }

    public static Result<T> OK(T value)
    {
        return new Result<T>(value, string.Empty, true);
    }
    public static Result<T> Partial(T value, string error)
    {
        return new Result<T>(value, error, true);
    }
    public static Result<T> Fail(string error)
    {
        return new Result<T>(default(T), error, false);
    }

    public bool Success { get { return _success; } }
    public T Value { get { return _value; } }
    public string Error { get { return _error; } }
}

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:

spoiler

public class Response<T>
{

    readonly bool _success;
    readonly T _value;
    readonly IEnumerable<Error> _errors;

    Response(T value, IList<Error> errors, bool success)
    {
        _value = value;
        _errors = errors.AsEnumerable();
        _success = success;
    }

    public static Response<T> OK(T value)
    {
        return new Response<T>(value, new List<Error>(), true);
    }
    public static Response<T> Partial(T value, Error error)
    {
        return new Response<T>(default(T), new List<Error>() { error }, true);
    }
    public static Response<T> Partial(T value, IList<Error> errors)
    {
        return new Response<T>(default(T), errors, true);
    }
    public static Response<T> Fail(Error error)
    {
        return new Response<T>(default(T), new List<Error>() { error }, false);
    }
    public static Response<T> Fail(IList<Error> errors)
    {
        return new Response<T>(default(T), errors, false);
    }

    public bool Success { get { return _success; } }
    public T Value { get { return _value; } }
    public IEnumerable<Error> Errors { get { return _errors; } }

}

Y este sería el de la clase Error:

spoiler

public class Error
{
    readonly int _code;
    readonly string _message;

    public Error(int code, string message)
    {
        _code = code;
        _message = message;
    }

    public int Code { get { return _code; } }
    public string Message { get { return _message; } }
}

Y esto serían unos ejemplos tontos de uso:

spoiler

public class ABCExample
{

    public void ResultExample()
    {
        var okResult = Result<string>.OK("success!");
        var partialResult = Result<int>.Partial(999, "error indicating partial success");
        var failResult = Result<bool>.Fail("error indicating partial success");

        // okResult.Success -> returns true
        // okResult.Value -> returns payload
        // okResult.Error -> returns string.Empty
        // partialResult.Success -> returns true
        // partialResult.Error -> returns errorMessage
        // failResult.Success -> returns false
        // failResult.Value -> returns default(T)
    }

    public void ResponseExample()
    {
        // errors returned in different inner processing (private methods) calls
        // one could make compile-time validations about integrity i.e; enforcing correct codes 
        // through an enum or some kind of const data structure.
        var myError = new Error(10, "user-facing error message");
        var anotherError = new Error(1, "user-facing error message");

        Response<int>.Partial(20, myError);
        Response<bool>.Fail(new List<Error>() { myError, anotherError });
    }
}

¿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.

Ranthas #2 Feb '20

#1 Después lo leo más en profundidad y te doy una respuesta en detalle.

En nuestra empresa colaboramos con un tercero que expone un servicio (API) que actua como un proxy, que a su vez consume métodos de una pléyade de API.

El proxy, facade o como cojones lo quieras llamar expone dos métodos: login, que te devuelve un token, y un doOperation, que recibe como input el token anteriormente mencionado, y un XML que contiene que la peticion a la API pertinente.

Cuando nosotros, desde nuestras aplicaciones tenemos que consumir esa asquerosidad, usamos una API intermedia nuestra que actua como gateway, y como en tu caso, hay veces que esa API nos devolvía un 200, pero la petición a la API "escondida" había fallado.

¿Nuestra solución? Al consumir las APIs detrás del proxy, nos llega siempre una respuesta de success/failure, y lo que hacemos es parsear esa respuesta. En función del error, lanzamos la excepción pertinente con un http.errorcode=400 si el fallo proviene del usuario, o un 422 si es un fallo interno de esa API, y que nosotros no podemos subsanar.

Si esas APIs de distintos colores y sabores devuelven siempre el mismo dto, este es el camino, como dirían los mandalorianos. Si por el contrario, te devuelven respuestas de distintos colores y sabores, tu idea la veo bien; un contra que le veo es que si este servicio sigue creciendo, el tema de los identificadores va a ser un puto infierno.

1

r2d2rigo #3 Feb '20 Inocente

Ni se te ocurra soportar partial success porque es un clusterfuck a todos los niveles. Una operacion o se completa o falla, no hay medias tintas.

No sobreingenierices con generics desde el principio porque estoy segurisimo que se va a dar el caso en el que un mismo endpoint devuelva dos tipos distintos y a ver como lo distingues con la estructura que tienes ahora.

No estas haciendo null check de errors antes de AsEnumerable.

Si la lista a a ser de solo lectura usa IReadOnlyList.

Ah, y con menos buzzwords las explicaciones se entienden mejor.

2 1 respuesta

Wei-Yu #4 Feb '20

#3 la idea es que la gente implemente el tipo, no que tire de generics dentro del código; sólo es un contenedor que poder reutilizar.

supongo que si el resultado "es parcial" debería manejarlo yo en la parte más externa en vez de tener ese mecanismo dentro de la clase; tampoco me gustaba la idea del todo cuando lo pensé pero no soy capaz de extrapolar el porqué, así que a ver si leo algo que me ayude a que cuaje

p.d: se aceptan sinónimos para las buzzwords shrug

Introducir result types en un proyecto vivo

Usuarios habituales

Tags