Conserva valores Y fallos en la auditoría
Requisito
Una auditoría de despliegue parsea ocho líneas de configuración
key=value, tres de las cuales tienen valores imposibles
de parsear. El informe necesita ambas mitades: imprime cada
key = value parseado con éxito, y luego un recuento de
los fallos. Las líneas están en el código; las dos versiones deben
imprimir la salida que aparece bajo Salida esperada.
Salida esperada
timeout = 30 port = 8080 workers = 4 ttl = 300 batch = 25 failures: 3
Lado a lado
RxDart
FxDart
Por qué difieren
El modelo stream lleva los errores por un canal aparte, fuera de
banda — y ese canal es terminal: una sola FormatException
termina la suscripción entera, llevándose las cinco líneas buenas con
ella. Para conservar valores y fallos, el lado RxDart tiene
que darle a cada línea su propio stream interno
(Rx.fromCallable) y convertir el error en datos antes de
que pueda escapar — onErrorReturn(null) aquí, con
null haciendo de «esta falló». Esa es la forma más ligera
que el modelo permite para una función que lanza (la ruta más pesada
de materialize reifica objetos de notificación
completos), y existe solo para deshacer una decisión que el modelo
tomó por ti: los errores nunca fueron valores desde el principio. (Los
dos paneles comparten a propósito el mismo parse que
lanza — con un parser que devolviera null ambos modelos podrían
mantener los resultados como datos planos; el throw es la premisa, y
lo que cada lado debe hacer al respecto es la comparación.)
El lado pull nunca pone los fallos en un canal, para empezar. El mismo
throw aterriza a un try/catch local de
distancia de volver a ser un valor ordinario — un record anulable —
así que el requisito completo es map y luego
partition: una pasada, dos listas, ambas mitades igual de
primera clase. Esta es la forma de la postura más amplia de FxDart
sobre errores tipados (sus pipelines de Either son esta
misma idea con tipos de error más ricos). Cuando los fallos son parte
del informe y no un final excepcional, mantenerlos como datos gana —
el veredicto se lo lleva FxDart.
Benchmark
N = 100
Tiempo Empate
Memoria pico Empate
N = 1,000,000
Tiempo Gana FxDart
Memoria pico Empate
Las barras son medianas de iteraciones cronometradas repetidas en procesos nuevos por lado (los N pequeños se agrupan por resolución del temporizador). Dos lados a menos del 5% entre sí — o a menos de 0.6 ms, una diferencia que nadie puede percibir — cuentan como empate; las carreras relativas ajustadas se vuelven a medir hasta 5 veces. En una app, cualquier cosa por debajo de unos pocos milisegundos es invisible para el usuario, gane la barra que gane. La memoria es el RSS pico del proceso. La VM de Dart y el dataset son idénticos en ambos lados, así que la diferencia entre las dos barras es lo que retiene el pipeline en sí.