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).
When refactoring recently the PHONE_MIGRATE_X error
wrt exception handling [1] I removed the dubious/obsolete
"settings" part, but I mistakenly removed the URL which
tells library consumers that if they face this exception,
it's actually a bug of the library that they should report.
[1] 77867b44e6
There are different kind of MIGRATE errors that could be
thrown by the Telegram API, as evidenced by this recent
change:
b06f8a8e11
So this rename tries to make it consistent to the new
exception names:
* FILE_MIGRATE_x -> FileMigrationException
* USER_MIGRATE_y -> UserMigrationException
* PHONE_MIGRATE_z -> PhoneMigrationException
Parsing the message of an exception to decide what to do
next is a bad practice, because it's easy that the message
might be changed by mistake in the future. To enforce the
coupling in a stronger way it's better to use exceptions
of different type depending on the kind of error, so that
we rely on the compiler enforcing the behaviour when doing
changes in this error handling areas in the future.
This also makes the code a bit more simple and readable.
Default value of max_id = 0 returns all dialogs
Should return a class with lists of dialog, messages, chats and users.
Add UserForeignConstructor to list of constructors
Add missing detail to DialogConstructor (PeerNotifySettings)
Unpack datastream completely to avoid issue with Ionic exception causing
problems in userForeign parsing
Use more recent code for Dialog construction
