Throw FloodException instead of calling Thread.Sleep()

Doing this is better when looking at the problem from at least
these 2 points of view:

a) You're working on TLSharp itself: You might be testing some
new things or running TLSharp's tests. Suddenly, if a FLOOD_WAIT
response happens, there's no clear way to know. You just see the
tests taking forever. But if a test has reached a situation in
which Telegram has returned a FLOOD_WAIT error, it's very likely
that what happens is that the TLSharp operation being tested is
actually buggy, which means that the test should FAIL FAST and
show a stacktrace of the problem so that you can see where in the
code was the FLOOD_WAIT received/caused. You shouldn't need to
kill the run of the test suite and hope to hit the problem again
only when you were using the debugger (to be able to pause
execution and examine a stacktrace of where the execution flow is).

b) You're using TLSharp: if you hit a FLOOD_WAIT problem it may
happen because:

b1) TLSharp has a bug: in this case it's better to throw an
exception so that the user can copy the stacktrace and paste
it into a new Github issue.

b2) Your program uses TLSharp sending excessive requests: you
want to have your program know when you hit the limit, to be
able to fix your program to not be so floody. But a call to
Thread.Sleep() doesn't help you to know this, you just know
that suddenly your program has hung, and you don't know why.
You cannot react to the problem, however with an exception you
can react to the problem (for example by examining the time
that the exception provides, as a TimeSpan property, to know
how much your program needs to wait to be able to use TLSharp
again).
This commit is contained in:
Andres G. Aragoneses 2016-11-01 23:38:28 +08:00
parent d8fca8619c
commit 5e9bb6163f
2 changed files with 15 additions and 4 deletions

View file

@ -211,8 +211,8 @@ TLSharp library should automatically handle these errors. If you see such errors
You should create a Telegram session. See [configuration guide](#sending-messages-set-up) You should create a Telegram session. See [configuration guide](#sending-messages-set-up)
#### Why I get FLOOD_WAIT error? #### Why do I get a FloodException/FLOOD_WAIT error?
[It's Telegram restrictions](https://core.telegram.org/api/errors#420-flood) It's likely [Telegram restrictions](https://core.telegram.org/api/errors#420-flood), or a bug in TLSharp (if you feel it's the latter, please open a Github issue). You can know the time to wait by accessing the FloodException::TimeToWait property.
#### Why does TLSharp lacks feature XXXX? #### Why does TLSharp lacks feature XXXX?

View file

@ -272,8 +272,7 @@ namespace TLSharp.Core.Network
{ {
var resultString = Regex.Match(errorMessage, @"\d+").Value; var resultString = Regex.Match(errorMessage, @"\d+").Value;
var seconds = int.Parse(resultString); var seconds = int.Parse(resultString);
Debug.WriteLine($"Should wait {seconds} sec."); throw new FloodException(TimeSpan.FromSeconds(seconds));
Thread.Sleep(1000 * seconds);
} }
else if (errorMessage.StartsWith("PHONE_MIGRATE_")) else if (errorMessage.StartsWith("PHONE_MIGRATE_"))
{ {
@ -499,6 +498,18 @@ namespace TLSharp.Core.Network
} }
} }
public class FloodException : Exception
{
public TimeSpan TimeToWait { get; private set; }
internal FloodException(TimeSpan timeToWait)
: base($"Flood prevention. Telegram now requires your program to do requests again only after {timeToWait.TotalSeconds} seconds have passed ({nameof(TimeToWait)} property)." +
" If you think the culprit of this problem may lie in TLSharp's implementation, open a Github issue please.")
{
TimeToWait = timeToWait;
}
}
internal abstract class DataCenterMigrationException : Exception internal abstract class DataCenterMigrationException : Exception
{ {
internal int DC { get; private set; } internal int DC { get; private set; }