Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to get ChatId on ChatNotFoundException? #831

Closed
davidcon opened this issue Aug 9, 2019 · 1 comment
Closed

How to get ChatId on ChatNotFoundException? #831

davidcon opened this issue Aug 9, 2019 · 1 comment
Labels
✔️ Resolution: Won't Fix Resolved because we decided not to change the behavior reported in this issue.

Comments

@davidcon
Copy link

davidcon commented Aug 9, 2019

I would like to request/propose a feature

I have seen on the code that when you send a test message

BotClient.SendTextMessageAsync(
                                chatId: new ChatId(Convert.ToInt32(idTelegram)),
                                text: texto,
                                parseMode: ParseMode.Markdown)

If this IdTelegram is not in BotChat, the wrapper throws an ChatNotFoundException.
On this excepction, in Telegram.Bot.Exceptions.ApiExceptionParser the information that elevates is only "chat not found".

I have seen that in the class Telegram.Bot.TelegramBotClient.MakeRequestAsync, a the end of the method, it reports apiResponse to ApiExceptionParser.
In this case of exception there aren´t any Parameter on the apiResponse.

If its possible to add more information to this exception, it could be implemented some thing like this:

if (!apiResponse.Ok)
{
    string requestStr = JsonConvert.SerializeObject(request);
    if (actualResponseStatusCode == HttpStatusCode.BadRequest)
    {
       Newtonsoft.Json.Linq.JObject json = Newtonsoft.Json.Linq.JObject.Parse(requestStr);
       if (json.GetValue("chat_id") != null)
          {
              apiResponse.Parameters = new ResponseParameters();
              apiResponse.Parameters.ChatId = Convert.ToInt64(json.GetValue("chat_id").ToString());
          }
      }
      throw ApiExceptionParser.Parse(apiResponse);
 }

Also I supose that ResponseParameters class has to be modified with new property ChatId like this:

[JsonProperty(DefaultValueHandling = DefaultValueHandling.Ignore)]
        public long ChatId { get; set; }

In the class Telegram.Bot.Exceptions.ApiExceptionParser.ApiRequestException may be introduce a new if case for ChatNotFoundException:

if (isBadRequestError)
{
     errorMessage = TruncateBadRequestErrorDescription(apiResponse.Description);
     if (typeInfo.Type == typeof(InvalidParameterException))
     {
         string paramName = Regex.Match(apiResponse.Description, typeInfo.ErrorMessageRegex)
                            .Groups[InvalidParameterException.ParamGroupName]
                            .Value;
         exception = new InvalidParameterException(paramName, errorMessage);
      }
      else
      {
          if (typeInfo.Type == typeof(ChatNotFoundException))
          {
             exception = new ChatNotFoundException(errorMessage, apiResponse.Parameters);
          }
          else
             exception = Activator.CreateInstance(typeInfo.Type, errorMessage) as ApiRequestException;
       }
}

public ChatNotFoundException(string message, Types.ResponseParameters parameters)
 : base(message, parameters)
{
}        

I think that is interesting to know if someone has left the BotChat to delete him from you database.
Do you know if exist any way to know if someone has left the BotChat before sending him a message?

Thank you very much for the wrapper. It works really good!!! :)

@tuscen
Copy link
Member

tuscen commented Oct 2, 2019

We've tried the approach with custom exceptions on different error results and abandoned it since it relies heavily on parsing of error messages. And they are not a part of public API, they can change anytime rendering all custom exceptions useless.

@tuscen tuscen added the ✔️ Resolution: Won't Fix Resolved because we decided not to change the behavior reported in this issue. label May 10, 2021
@tuscen tuscen closed this as completed May 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✔️ Resolution: Won't Fix Resolved because we decided not to change the behavior reported in this issue.
Projects
None yet
Development

No branches or pull requests

2 participants