Re: aedis review starts today

From: Marcelo Zimbres Silva (mzimbres_at_[hidden])
Date: 2023-01-23 07:56:51

On Sat, 21 Jan 2023 at 20:00, Ruben Perez <rubenperez038_at_[hidden]> wrote:
>
> 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