Propagate exceptions occurring during client instantiation

[PattaFeuFeu]

Description

This PR improves our error handling when instantiating a MastodonClient through the Builder#build function.

This closes #282 which was an issue originally created because we found out in #280 that exceptions were just swallowed without doing anything. This resulted in a user of our library not figuring out easily that they were trying to call network code on a main thread.

The main issue in our client instantiation is that we need to get an instance version to know what we’re dealing with. Whether that’s even the case or if we could restructure our code to no longer need that is a different topic which I did not handle here.

I introduced a few new custom Exception classes which are returned in specific cases where we either cannot get server information, a NodeInfo’s URL, or an instance version via the API v2 or v1.

I tried to catch only those exceptions that we throw ourselves and not intervene with any more general or other exceptions. This way, I/O exceptions, security exceptions, … should just be propagate uncaught to the caller.

I have kept the double fallback solution for the instance version:

1. Get instance version via NodeInfoClient
2. If that fails, get it via the Mastodon API v2
3. If that fails, get it via the Mastodon API v1
4. If that fails, throw an exception that has both the failure of the last Mastodon API call and the initial failure of the NodeInfoClient as causes, if possible

Type of Change

• Bug fix
• Documentation

Breaking Changes

• MastodonClient.Builder#build may now throw a BigBoneClientInstantiationException. Java clients will no longer be able to build unless they either surround the build call with a try/catch block or add the exception to the method signature of the function calling the builder.

How Has This Been Tested?

I have added new unit tests and tried the “Get public timeline” sample with both existing and non-existing Mastodon servers, with an existing Internet connection and without one.

Mandatory Checklist

• My change follows the projects coding style
• I ran gradle check and there were no errors reported
• I have performed a self-review of my code
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• KDoc added to all public methods

[codecov]

Codecov Report

Merging #353 (b2d74ee) into master (8d8da41) will increase coverage by 48.00%.
The diff coverage is 62.24%.

Additional details and impacted files

@@              Coverage Diff              @@
##             master     #353       +/-   ##
=============================================
+ Coverage          0   48.00%   +48.00%     
- Complexity        0      501      +501     
=============================================
  Files             0      137      +137     
  Lines             0     3704     +3704     
  Branches          0      242      +242     
=============================================
+ Hits              0     1778     +1778     
- Misses            0     1734     +1734     
- Partials          0      192      +192     

Files	Coverage Δ
...i/exception/BigBoneClientInstantiationException.kt	44.44% <44.44%> (ø)
...e/src/main/kotlin/social/bigbone/MastodonClient.kt	43.56% <78.57%> (ø)
...n/kotlin/social/bigbone/nodeinfo/NodeInfoClient.kt	48.48% <37.50%> (ø)

... and 134 files with indirect coverage changes

[bocops]

Looks good to me. Sections pointed out by you as debatable should work either way for the time being. :)

[PattaFeuFeu]

@andregasser Do you want to check this yourself as well? Otherwise we could merge this soon. 😊

[andregasser]

If I could have a quick look at it would be awesome. Will do it today, ok?

[andregasser]

Please see my other comment.

[andregasser]

👍