Re: aedis review starts today

From: Marcelo Zimbres Silva (mzimbres_at_[hidden])
Date: 2023-01-21 17:47:01

On Sat, 21 Jan 2023 at 18:28, Ruben Perez <rubenperez038_at_[hidden]> wrote:
>
> > I know Boost.MySql invented error_info to deal with this problem. I
> > did not adopt it because
> >
> > * Deviates the completion signature from well established practice of
> > having error_code as first parameter f(erro_code ec, ...) or
> This is not true. error_info (now server_diagnostics) are never
> part of the completion handler signature, but populated by lvalue reference.
>
> > * Requires additional parameters to the completion e.g. f(error_code
> > ec, error_info ei, ...)
> Again, this is not true.
>
> > * Raises question about who allocates the string.
> The string is allocated as any other data passed by lvalue reference.
>
> I'm not saying error_info (aka server_diagnostics) is the solution,
> but none of these arguments are true.

Indeed, it is passed to the initiating function
https://anarthal.github.io/mysql/mysql/ref/boost__mysql__connection/async_query/overload2.html

template<class CompletionToken>
auto async_query(
    boost::string_view query_string,
    error_info& output_info,
    CompletionToken&& token);

Which is similar to what I am proposing in the github issue I point
you at. Sorry for the confusion, I have discussed extensively with
others why not pass in the completion handler and though I had seen
this first in Boost.MySql when I wrote a review.

> > * The error information is also only useful for logging and the user
> > can't react to it so why not log it right away.
> I'm not getting this. How can I log something if I can't access it?

A high-level library might decide not to pass this information to the
user but log it right away. Users will react to error_code and not to
error_info which AFAICS is only used for logging.

Regards,
Marcelo