mirror of
https://github.com/sochix/TLSharp.git
synced 2025-12-06 08:02:00 +01:00
5e9bb6163f
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). |
||
|---|---|---|
| .. | ||
| MtProtoPlainSender.cs | ||
| MtProtoSender.cs | ||
| TcpMessage.cs | ||
| TcpTransport.cs | ||