On Sat, 21 Jan 2023 at 18:28, Ruben Perez
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_qu... 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