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
This change is good because:
a) It's better to target a lower target framework version if
the project doesn't necessarily depend on the new features
of the newer versions (so, bigger target audience).
b) It lets compile the project with implementations of the
.NET Framework that are not compatible with 4.5.2. For example,
after this change I can successfully build TLSharp with the
Mono v4.2.1 that comes in my Ubuntu Linux 16.04.1.