On Sat, 21 Jan 2023 at 20:00, Ruben Perez
I think error handling at the command level is flawed, though. If a command fails, the entire pipeline operation fails, and no easy access to the diagnostics is provided. I've also seen that Redis will execute all commands in a pipeline even if an error is encountered in one of them. So, in pipeline [C1, C2, C3], if C2 errors, C3 is still executed. The API should provide a way to access C2's error and C3's result. The proposed solution in https://github.com/mzimbres/aedis/issues/40 seems insufficient to me. I'd give Boost.Leaf (or a similar solution) a thought.
This is to make it safe by default and in part because Aedis is centered around the adapter. In the same sense that you can write an adapter to receive responses in the data-structure that makes most sense to the application e.g. std::map, std::unordered_map, boost::flat_map etc. You can also customize the way errors are handled. For example, * Errors like type mismatch are usually unrecoverable and you might want to fail fast and let the async_ operation itself fail instead of proceeding in an unknown state. * If you can tolerate errors like that you can write an adapter that does not communicate an error to the parser. I did not make this the default because it looks unsafe, people will usually expect async_exec(req, adapt(resp)) to throw when the response can't be stored in resp. I am perhaps at fault here for not documenting this feature. I thought however not many people would want this behaviour. Regards, Marcelo