Saving and providing failure error codes.

int main(int argc, char** argv) {
    using namespace banana::connector;
    beast_blocking_monadic connector("<TG_BOT_TOKEN>")
    auto resp = banana::api::send_message(connector, { /* .chat_id = */ "@smertig", /* .text = */ "Hello, world!" });
    if (!resp) {
        cerr << string(resp.error()) << "\n"; // providing string-based error message
        switch(ErrorCode(resp.error()) { // additional error-treatment based on the codes
            case ErrorCode::ConnectionTimeout: ...
            case ErrorCode::Deserialization: ...
            case ErrorCode::RuntimeError: …
            case ErrorCode::Serialization: ...
            case ErrorCode::ConnectionWrite: ...
            case ErrorCode::SSL*: ...
        }
    }
}

Let's say we want to retry the request for particular failure reasons only or treat the errors differently based on the underlying reason - there is no way to do that at the moment because of string-based errors.

From the client-side, it's substantial to distinguish between connection(SSL, read, write, bind, lookup, timeout) based errors and serialization/deserialization, std::errors,ok =false, other C++ errors.

This issue proposes either of two options:

Creating common failure error codes for all the bundles based on HTTP, libcurl, whatever, allow setting them within the connectors and save as an edition in struct error_t class. Those error values may not be present, we can store ErrorCode::Unknown by default, but if additional error parsing is available by the bundle - see the CPR as an example, the banana will provide it to the end-user. You are already converting the error codes to string in cpr.cpp, so in theory, it's possible to preserve error codes as well.
Storing different error-code values based on the chosen connector - this will allow more sophisticated error treatment but might break the idea of the common template-based interface. I would prefer the option which provides more detailed error treatment - if the error codes among bundles can't be kept consistent, so be it.

Let me know your thoughts here...

Smertig / banana

Saving and providing failure error codes. #9