Feature Request: make error_handler in Dispatcher able to accept deps

[syrtcevvi]

I want to cover the use-cases when a bot has to notify user about "unavailable api" or any other typed Error (not just Box<dyn Error..> )

So, now when an error occurs it's just logged. For simple cases it's enough, but personally I want to describe error handling in one place, i.e. in error_handler section of Dispatcher.

This is how I see the scenario:

struct PublicError {
  Dummy,
  ApiError(&'static str)
}
// In case we have function-like error_handler:
// The *user* and *message_text* are deps
pub async fn error_handler(bot: Bot, user: User, message_text: String, error: PublicError) {
  match error {
   // We ignore possible error from message sending. If things are that bad, we don't care
    Dummy => bot.send_message(user.id, "Dummy error").await,
    ApiError(_) => bot.send_message(user.id, "The internal error occured, please, try later").await
  }
}


// Or if we have struct and the access to the user's (chat's) deps:
// Somewhere inside the ErrorHandler struct' handle_error

let bot = deps.get()
let user = deps.get()
match error {..} // The same as previously

Also, I found, that it's relatively easy to implement here, i guess, so the actual question is the shape of the result: will impl ErrorHandler accept deps as a parameter or can it be implemented similarly to UpdateHandler, i.e. async fn that accept deps as it's actual arguments along with the Error

Pros

• It will make error handling more flexible due to the additional context
• It can introduce the way to show teloxide developers how to handle typed Errors (with notifying bots' clients that they do smth wrong within their dialogues). So that I could write the example of that

Cons

• Requires a lot additional work to implement the latter case (deps as arguments)
• Introduces breaking changes (I don't think that someone uses custom error_handlers other than just logging or ignoring, but I can be wrong)
• It requires a bit of design due to the fact, that different errors may require different set of deps (if error occurs early, it can miss something that will be introduced down to the handler tree, but personally I rarely need more than Bot, User and Message)
• Not clear what to do with errors which are introduced from error_handler (just ignore them?)

Alternatives

• I don't think that passing, for example, UserId's as part of Error enums would be the same-level alternative (looks tedious)

[WaffleLapkin]

I think allowing "deps as arguments" is a bad idea for the error handler. You don't generally know what's the context the error is coming from & which dependencies are available.

Passing DependencyMap seems like a good idea (although we'll have to add a fallible API to it).