If a method that returns bool is never returning false,
it's essentially not giving any information at all, which
means that it should return void. This will help the
consumers of this API to stop thinking that the result
of this function means if the connection was succesful
(which it is, actually, but it was never returning false
because if there's any problem connecting, the result would
be an exception instead).
The method IsPhoneRegisteredAsync() was calling
RequestWithDcMigration() which was the real method
that made use of the _sender field, so we can move
the null check to there.
This will also help track down possible NullReferenceExceptions
that could happen when other callers of this method
arrive with a bad _sender, which might aid us trying
to fix#706.
Load() method in ISessionStore requires public constructor of class Session in some cases.
E.g., loading session from a db or a key-value store, manual loading from text-file, JSON/XML and so on.
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
Instead of throwing a System.FormatException, capture the URL
thrown by the library itself so that the developer configures
the API_ID and API_HASH and places them in the app.config file.
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.
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.
