* Add some tests to be completed
* Actually fail the tests
* Create AbuseException class
Copied from ForbiddenException and then gone over to inherit from it.
* Actually add AbuseException to csproj
* Update test file
* Ran .\build FixProjects
* Test updates
* Default message update for AbuseException
* Separate the exception creation logic
* Remove message assertion -- doesn't matter here
* Additional test for abuse message
* Remove unnecessary variable assignment
* Failing test for unsafe request
* Attempt to fix test
Still broken -- I don't think empty strings count to trigger the default
message
* Remove test that will always fail due to another issue
Opened #1529 to explore this.
* New tests (some failing)
* Passing tests are, like, better than failing tests.
* Last passing test
* Cleanup
* Add test for zero value and fix code
Lol boundary cases.
* cleanup
* Mark ParseRetryAfterSeconds as static
* Add GetObjectData override to AbuseException
To include data for RetryAfterSeconds variable, and satisfy the build
check.
* Add back failing test & skip it
* Change to nullable int with null default
* Fix tests around nullable default
* whitespace fixes
* Compact the logic; tests still pass
* Invert the if statements for compactness / clarity
* Test subclasses & reformatting
* Test name changes
* Whitespace fix
* Remove redundant line
* Add HTTP 451: Legal Takedown Exception.
* Add LegalRestrictionException in HandleErrors.
* Cast 451 to HttpStatusCode and include exception in csproj files.
* Tests added and "FixProjects".
* Fix: 403 -> 451 in 451Tests.
Added a RateLimit class to encapsulate pulling rate limit information
from the headers. This is now exposed by ApiInfo as well as the
RateLimitExceeededException. That way these two classes are not grabbing
the same information in different ways which we were doing before.
Right now, our exception messages come from the API response in most
cases. But if for any reason there isn't one, we supply a default. I
realized these messages might make it to people's logs so it might be
nice to spend time later making them even more useful.
If a 3rd party client needs to provide a specific HttpContent, we should
allow that in the adapter. Our clients probably shouldn't do this as it
would break encapsulation.
