Error handling

[Lonami]

Method calls can fail due to network issues, or be caused by bad requests (such as invalid input parameters).

• Should we use a result inside a result to signify first network error and then request error? This would make it easy to propagate network errors, and handle request errors.
• Should we use a custom enumeration with either network error or request error? They can't happen at the same time, so this makes sense. Should this impl From<...> for io::Error to propagate it easily?

How should flood waits be handled? Should the library have a flood sleep threshold? What about automatic reconnection? Which layer of the design should deal with this?

[swarnimarun]

I think that the connection manager should be responsible for all Errors, but I think you wanted to ask should or shouldn't we pipe up the errors. And as such I don't necessarily know but I would guess that the user of the library would prefer a way to fetch the current/response or error.

So to have custom Errors would make sense.

And easy way to appease everyone is to impl From for the CustomError to Rust Error Types.

[swarnimarun]

After looking through more TG API, what I meant was Errors should be propagated through mtsender to Client API. And served to the library user via Custom Errors for saner Error messages, if they unwrap it. Or for matching over them. And have From for allowing automatic conversion to more neutral Error types commonly used by Rust.

[Lonami]

I think that the connection manager should be responsible for all Errors

By this do you mean one of the libraries should deal with network errors and reconnect when appropriated? Of course, if this fails, it would be propagated upwards.

the user of the library would prefer a way to fetch the current/response or error

Yes, definitely. For example, trying to send an empty message is a bad request error, but the connection being lost (and the library being unable to reconnect and retry) should be a network error. Both of these should be propagated up to the user, so they can handle it.

My point was more about, whether to use a custom enumeration to represent "either bad request or I/O error", or to use a nested result "the network may fail, and then the request may have been successful".

For improving the error messages of bad requests, we can document some of the known, but since there is no official list on what the error names mean, we can only do this on a best-effort basis.

[Lonami]

The names are subject to change, and I don't like the fact we're currently abusing an AuthorizationError can come from an InvocationError, so the examples just use the former (even though most requests won't ever cause an AuthorizationError).